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ABSTRACT 


Each programming language that handles data structures 
has its own set of rules for working with them. Notions 
such as assignment and construction of structured values 
appear in a huge number of different and complicated ver~ 
sions. This thesis presents a methodology which provides a 
common basis for describing ways in which programming lan- 
guages deal with data structures and references to them. 
Specific concern is paid to issues of sharing. 


The methodology presented here consists of two parts. 
The base language model, a formal semantic model introduced 
by Dennis, is used to give the work here a precise founda- 
tion. A series of “mini-languages" are defined to make it 
Simpler and more convenient to expreas and-describe the 
semantics for a variety of constructs found in contemporary 
programming languages. 
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Chapter 1 


INTRODUCTION 
1.1. General Goals 


Students of computer science are PONEZONEOG: at a VOry 


Sane stage with a great Riese of general-purpose } pro~ 


gramming languages. Descriptions of / these ‘Languages ae 


Saal eee) mS cA 


heavy eumpiiaieie on common features auch as assignment, ee 


cedures, aonaitionals, Gneae/ateouks and block | structure. 


Aside from variations in notation, there are numerous ‘jaled: 


exceptions and special cases which make for differences be- 


tween comparable constructs in different languages. For ex- 


ample, the body of a DO-loop in FORTRAN must be executed at 


[body] 


50 CONTINUE 


body executed once { body not: executed 


Fig. 1.1-1. Looping feature in two languages 


Pe shteagnobe: aaNet eee coy inwaetaert eng: oot 


. -6=- 


least once, while in PL/1 it is to be skipped if the index: 
is out of range (figure 1. 1-1). Such differences can be 
studied by examining the semantics of different programming 


languages. The semantics of a / pepgresming penguese. is the! 


2 amy ie ed ; 4 2.2 
study ‘Of the meaning Of ‘its constructs, or in other words 
ey NET ae ia se e ° 
the effect of executing programs in the language. The boos 


‘ rus E abi epTa i Pha o? 


cieitaes concern oe aie thesis is the notion of data Stra. 


we type eyo eos CM ATEAT: 
A, AES 


‘coves yaa ‘the ‘semantics pertaining to ‘then as _ they | appear 


in Score ine. Languages. 


TS. ak 


There are many areas Of b appligatign. in, “Wpieh, the.use. of 
structured Gata ie both helpful and convenient. in. problem. 
solving. “Some axeep ie areas are ‘symbol. manipulation, arti- 
ficial intelligence, computer graphi¢s, and simulation stu- 
dies! "Generally speaking, a data structure is an 1 aggregate 
data object “gentatning other data objects as components. 
Typscet inetasces ‘of deta structures ihetnds- arrays, sequen— 
ces, wecteen: ‘taples and lists. We will not dwell on the 
characteristics. pecditad to each of these different vari- 
eties of data peoiete: our emphasis: wil: be on'more gener- 
al properties.selating to data structures. and their -compon— 


f 
ents.. 


ae Ce v sok 
reper ckS Mat We acd 


Typically, a programming language provides two basic 


Saat chan Py ee oP ee a : Tacks er ee ES 


a, 


operations for handling data structures: Senora fic apie 
of a data structure can be individually accessed and manip- 
dtated. and data structures can be constructed from 1 desig 
nated Spieets as components. These "operations interact with 
the assignment operation of a programming language in n per 
forming several other faska, such as assigning structured 
values to identifiers, or upaaeing SOiipenente t of a atric 
ture. There isa great similarity in appearance among eons 
structs for performing such tasks in Jadious. péogranéiae - 
languages. On the surface, from a casual examination of 
language descriptions, distinctions between analogous con- 
structs in different = Languages appear to “be, mostly notation~ 
al. But we shall see important eee ao par 
ticularly in the area of data being Saved reevecs aifferent 


structures. 


Since each programming aves has its own set of 
rules for dealing with data structures and sharing, it is. 
desirable to seek a rigorous method for describing what 
happens. Our goal, then, is to gain a more precise under- 
standing of the semantics of data structures. This will 
provide a unified and coherent viewpoint for descxiping the 


different approaches to data structures as they are found in 


she CRATER PLS ROS ne 


~8- 


programming Languages. We will: BAY specific attention to 


the aifticult and important issue of properties of sharing: 


ee 


These issues depend ultimately on. “the ea th of cells 


“Sh 


(whieh model computer memory locations) and references to 


celle. References are also commonly eaten ‘as pointers. We 
will first discuss general qeee ons of programming language 


semantics, and then move cOMaES# a more ‘Specific treatment 


of date gtnucturds and references. 


. A programing language provides | a “notation in watch: he 
programmer can model ‘computational processes: ane the ae: 
mation on whieh hey. operate. Programming ‘Language seman~ | 
tics deals with. the retntionsnip between programs and the 
objects they represent. A formal semantics for a programm— 
ing VanGuage is a precise description of such a relation- 
ship. There has been Pa study of ‘formal semantics of pro- 
gramming ‘languages. wesder [weg Fa) ‘distinguishes three | 


classes of foxmal ; semantic modele: 


E te eG 


(1) Abstract Semantic models. In this Approach, the. 


cbiests being modeled are treated aa ‘mathematical entities 


lee 


Pistersenidien & of any eae veiccasntationc. uedova of 
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this class aim towards. prov sara a a formal mathematical de- 
séription of the compute ctenal notions | being studied. one o 
well-known example of this seer Bah, to ‘semantics has Sean, 
the use of the lambda. calculus as a Pekan eae A ie oe. 
gramming languages. The lambda ¢aiculus; which’ is described 
in [Der 74, Morr 68, Weg 68], is basically A‘mathematical 
formalism for the definition and application of functions. 
It is ideally suited for describing so-called applicative — 
features of programming languages, such as evaluation of ex- 
pressions, use of procedures, and ‘block structuring. anaie 
demonstrated its usefulness in these areas [Lan 64] and pre- 
sented a scheme for extending the lambda calctlus formalism 
to model the language ALGOL 60 [Lan 65). More reckuely, 
different extensions of the lambda calculus have been de-~ 
vised for describing data types [Reyn 73]. | 

A second major example of ‘the ¢ abatract approach to se- 
mantics is found in the work. of Scott [Scot 70, Scot 71). 
Scott makes use of the isi thonat cat 2eheory st fadtices 
[San 73] to construct sets which are the déiatia of Zanes” 
tions that represent the behavior of programs. The Scott 
formalism has been used récéntly to deseribé the semantics _ 


of ALGOL 60 [Mos 74}. 


Yee Ai: PM remy epee Soe a ep ees 
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we can briefly * atmmaciee abstract “semantic | models by saying 
that they characterize the action oF programs as functions ' 


ey 


over various domains. 


(2) es t models. ‘Models. of this class use 


statements of mathematical logic. as. agsextions, _about . the 
state of a computer syatem at various points during the ex- 
ecution of programs on it. The. sementics ofa program is — 
viewed as the relation between input assertions (the state ' 
of the system before execution) and output assertions (the 
state after the program is run). This approach to semantics, 


more Semmens ey cates the SRE RPI Nin Oe. ONE 


been ‘much further work on it. “axtomagic sembasice demoat 
useful. in proving correctness of, programs, i.e... establishing 
that the effect of pxecating a oe folssi ie. mathematical 


conditions the Program an supposed. t9 satiety. 


(3) overstional models | This appraach. to, semantics 
concernsitself specifically with modeling the changing Oy 
states of a computer system performing computations. Such a 
task is usually accomplished by means.of a atate-transition 
system, in which a state-of the model represents the pouee~, 


mation in the computer system at a given time. The effect 


“47= 
of a program on its eee data is me tlectes in eee Hacer 
of transitions of the model. It is | important to observe 


¥ 


that given a state-transition system corresponding to some 


Me 


program, the sequence of states ener: models the SRGCUETOR hee 
this program defines ne aeelon. of an interpreter for the 
program. For this reason, the approach to formal semantics 


using operational models is called interpretive semantics. 


We can Gepcrtbe the way in which an ieee aoe seman- 
tic model gives the semantics EOE a Progrey written in some 
source language. A translator Shane zOEWE the Progra into” 


an equivatent program in another Language, which we call. an 


abstract language. Programs in an abstract ieaguace:: are. 


acted upon by an interpreter; this action results in a 

sequence of state transitions of the aaie ‘The semantics 
of the original source~language program is given by such a 
sequence of transieions. One reason we make use of trans- 
lators is that source programs = usually represented oa 


character strings rather than as data objects suitable for . 


processing by the interpreter. 
Although the use of interpreters to implement pro- 


gramming languages was (and still is) commonplace, McCarthy 


[McC 62] was the first to use an interpreter to define a 


~12- 

language’ (LISP) . The semantics of LISP is given formally by 
an interpreter written in LISP. Landin (Lan 64, Lan 66b] | 
uses an interpreter called the SECD aching 3 to define the 
lambda caleulus; even though the: “Lambda culeuiue isa _ mathe- 
matical formalism with a igeresa definition of its own. A 
more vecent @lucusetsh of definitional ieatpretece aaceound 

Of these three approaches to formal semantics of pro- 
gramning languages, the interpretive approach ‘ie best suited 
for our ‘Goals of understanding the semantics of data struc 
tures and references. In order to properly expiain the se- 
mantics of a program that handles data structures, we will 
néed to know how the data structures are formed, thets: com— 
position, the relationships petween the structures and their 
components, snatiag properties, and other items of Anfor- | 
mation. The best way to sat: a handle, on bene kind of infor- 
mation is to consider the state of the system at varpous ‘ 
moments during the gxecution of the program. The interpret 
ive approach is the only one which lends nee to 
working with states of the system. Both of the other 
“approdches ‘are bettér suited for proving assertions about 


programé and’ establishing their correctness; but these 
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issues are outside our main concern here. A treatment of 
data structures from the iewssine of axiomatic semantics 
may ‘be found in ey 74]. We will WOES Toney os developing 
an interpretive nodel to be used as a “semantic foundation | 
for dealing with the important issues of data, structures and 


references. 


The aoe prominent interpretive model for semantics is 
the VDL model. VDL, the Vienna Definition Language, is a | 
me tackanguase for ree interpreters of ‘programming Lan 
guages. VDL interpreters have been + written for “Languages : 
such as ALGOL 60 [Lau 68], PL/L [wate 69, Luc 691, Can Abe 
PDP-8 machine language [Lee 72). An | elementary snteodustion 
to VDL may he: Eoin in [Weg 72). Just as. LISP works with. 
lists, VDL weeks with tree-like data objects (which | we call 
labeled trees). The bneie operation of the VDL model is as 
follows: for each source language wisee fe semantics we wish 
to describe, we define a ana labor and an interpreter. The 
translator transforms a source language program into an as 
stract program, which is a forin of labeled teas cultabié for 
manipulation by the interpreter (for each ous 1 ancuace. ; 
the corresponding abstract language will be some set of 


labeled trees; the structure of an abstract program varies. 
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‘from Language to language) . The interpreter, which consists 


of VDL code, accepts a “labeled tree as input | and capuerpr ers 


af 


the effect of the Program on ite input data. For Set fezent 


languages, ‘ifferent interpreters : are defined. 


The fact that VDL uses treelike data objects reduces. 


its desirability as a semantis meren for our wore on data 


eas nee hy coe: 


structures. we will be studying data Beds dole uh dat in which 


components may be: shared between different objects; VDL" Ss 


ig 


labeled trees do aoe directly admit E sharing of any kind. 


hus in order to model in vl, structures such as we Slee 


fhe Ey ee 


rer it would: ‘Be “necessary to go through the inconvenience 


sez f é 


of simlating ‘the | memory of a computer. Since the , study of 


sharing is fundamental to our = work, ait is desirable to work 


. vA 


with objects in which sharing . is “represented directly. We 


MO Come Bee 


tharetove prefer for our “goals” a | semantic model nae: 


manipulates gate “objects « of. a more general | Bature: than VDL" 8 


labeled ‘trees. 


oo pena 72), Dennis outlines an interpretive semantic 
trode! called the bage language mogel.. .The. data objects mann 
ipulated by this model are variants of directed graphs and 
can directly model sharing. As with VDL, for each language. 


whose semantics we wish to describe, we must specify a 
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translator which transforms programs in the language into 
data objects suitable for consumption by the model. These 
objects are called procedure structures’ in the base language 
model. Procedure structures, like. ¥DL's abstract prograns, | 
are acted upon by the interpreter to produce state tran- — 
sitions. But the base language model’ differs:from ‘VDL in 
that the composition of a. procedure ‘structure ‘generated by . 
the translator from some source. program does not depend on 
the language in which the program tancvetteen =) AS a result, 
there is no need to define a separate interpreter for. each 
programming language. There is a single, pre-supplied in-.. 
eataretes for the base language model which accepts arbit-_ 
rary phenedune structures and interprets. them as programs, . 
Thus we see that the translators for the base langage nedel 
eopeiete programs from their respective source languages 
into a single, common language. We call this language the _ 
‘sie language. A procedure structure represents a program 
in the base language, which consists of a sequence of in-- 
steuseiors: The individual base language inatructions spec- 


ify the fundamental state transitions of the model. — 


In order to achieve the language-independence of the .. 


interpreter in the base language model, the translators met. 
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do more work than their VDL counterparts. A VDL translator 
simply converts. a program from character string to labeled 
tree, while a translator for the base language model must 
perform. functions similar to thosé of a compiler. ‘Thus, 
‘once we specify.the semantics. of the base language, i.e. 
decide on a formal specification of the< actions performed by 
the intexpreter in the base Leaqinge waded; the semantics of 
a particular programing language is determined by its 
translation into the base language. 

“mhe’baiae adiguage wodél’ ie extremely well suited for 
our work. “The primitive instructions of the eace Lenauaae 
are particularly convenient for manipulating pcructared ob- 
jects and dealing with sharing. We can view ‘the, base lan= 
quage asthe machine tangaige’ for’ computer with heap- | 
structured memory’ and symbolic address space. In this ‘re= 
spect, programs in the base language will be dimiiar -t5 cane 
vetitional assembly “language programs. ‘ghia aimtlarity is a 
source of further convenience in using the base language as. 
a programming tool. wieu _ 

Amerasinghe [Amer 72] described the translation of a 
block=structured language BLKSTRUC fate tke base language. 


Ii: BLKBYRUC, procedures aré "first-class objects" [Stra 67] 


Ss ae ae 


which can be used in contexts as general as objects of other 
types. _BLKSTRUC's treatment of procedures is more general 
than ALGOL 60's. The action of a translator for a language 
with Aeaslocad goto's te described in eee 73). Trans-_ 
lators for the languages: shonond and Simula 67 are discussed 
in [Dra 73] and [Cou 73). These ue show the use of the 
Saas language model in deackitine the semantics of venous 
powerful programming languages. We willbe using a version 
of the pase language model as the semantic foundation for 


our study of data structures. 


1.3. Plan for the Thesis. 


We outline here the topics covered as the rest of this 
thesis. Chapter 2 describes the base language model as we 
will be using it. The action ee phar interprabe: is given by 
describing the effect of the fatmiciiona of the base 
language. The approach in Chapter 2 dia ingommals a WES 
rigorous treatment is found in the. ependens once the be- 
havior of the base language interpreter is known, we have a 
handle on the semantics of the programing-Lafgquage con- 
structs that interest us. All that will then need oe 


done to supply a formal semantic definition is simply to 


‘deseribe ‘the action of a translator which: Produces bane lan- 


guage: céde. 


“In the remainder of this thesis we will be using the 
base fandiage acd as a semantic foundation for Geseribing 
the different ways ‘various programming languages deal with 
date structures. We want to eake clear distinctions between 
‘comparable cohatrasts or ai fferent languages. _ Although the 
semantics of data structuring constructs © can be pEecisely 
‘ expressed. by using the bane language model, eueee isa cer 
tain respect in which the model is igae eben ideal as a de- 
scriptive vehicle. Data structures .as they are found in — 
‘programming languages are tied up with she notions of var- 
fables and values. We .would like to make use of these 
notions ih: talking about the semantics of data Structures. 
But the ‘Menovipeies level of is base “language is only 
‘equipped for talking about primitive transformations on the 
objects which eomptias the interpreter states. In this | 
wonea the pase wagons is too "low-level" for describing | 


data structures in a manner suitable for our purposes, — 


$ 


To provide a better descriptive mechanism, we will 
follow the approach taken by Ledgard [Led 71] in defining a 


series of "“mini-languages." Mini-languages provide de- 


scriptive levels appropriate to our needs, yet at the same 
time segtarene syntactic and semantic complexity of full-. 
scale programming languages. The primary advantage of the 
mini~language approach is that we can isolate the concepts 
we wish to describe by eliminating all the conceptually ex- 
traneous notions that are needed in a full-size language. | 
maadeaingiy, in'a mini-language for describing data struc— 
tures, there are no procedures, Conditional expressions, , 
loops, goto's or operators. Mini-languages are not meant to 
be viable languages for actual programming; they are used. 
Fox descriptive purposes only. The syntax and semantics of 
a mini-language are simple enough to be readily understood 
on an imgorkel basie; the semantics eee eae be formalized 


Seca 


by specifying translation into the base language. In this 
manner, the semantics of data-structuring constructs in full- 
scale programming languages can be given by describing how 


to express these notions in a suitable mini-language. 


Chapter 3 presents mini-languages for describing the 
notions related to assignment, data structures, pointers and 
sharing. These mini-languages are then iasanke describe the 
data structuring semantics of wavetal full-scale programming 


languages. 
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In Chapter 4, we treat the additional notion of static 
typechecking, which has a direct bearing Sn che semantics of 
data structures in many important Epo lematng danjuecees: 
This notion of static typechecking differs’ from Ledgard's in 
that it deals with structured types, where Ledgard [Led 71) 
deais with functional types and the types Of arguments and 
returned values. As in Chapter 3, we treat the data struc- 
turing facilities of three full-size languages; in” 
these languages the concept of static typechecking is di- 
rectly tied in with the semantics of data structures (spe- 
cifizally assignment) . a ra a 

Chapter’ S presants a summary of what we cover in this 


thesis and suggests extensions for further study. 


‘er im 


Chapter 2 


THE BASE LANGUAGE MODEL 


2.1. Overview of the Model 


We have chosen as the semantic foundation for our work 
a version of the base language model. set. forward in. {Denn, 71] 
and [Amer 72]. The base language model centers around a. 
base language interpreter, which is essentially a. gtate- 
transition system that we shall use to express the meaning 
of computations. The interpreter specifies the behavior of 


an entire computer system. We represent.a computation by a. 


sequence of interpreter states. A state of the interpreter 
will be a cerca kind of mer neueecce> rabiect enbosying the 
information contained in the computer system at a partic- 
ular point in time. We shall define a base Language called BL 
each of whose programs ‘consists of a hagas esses of instructions. 
Each instruction specifies a functional. transformation oo 
tween intercrater states, The language BL is adapted fron 


the rudimentary language described by Dennis in [Denn 71}. 


We represent interpreter states by mathematical oS 


jects known as | BL-graphe. gupsoaw. we are given a Bet ELEM 


i 
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, of elementary objects and a set SEL of selectors. (For our 


kop tet 


purposes, ELEM consists of integers, “real numbers and 

strings; SEL consists of integers and eteings. - nen a 

BL-graph is. a variant form of dieected graph; it consists of 

nodes and arcs. Each arc connects two hodés in a specified 

direction and is labeled with a selector. we may associate an 

elementary’ objeet with each’ node from whith no arcs lead 

out. ‘There must also be a distinguished subset oF the 

nodes (called the root nodes) from which each node of 

the graph can be teached along some dirécted path of ares. 

We give a formal ‘mathematical definition of BL=graphs in the 

Appendix. © ia 
A BL~graph with: a single root Note is called a ‘Bucobject. 

We identity a BL-object by its ‘root ner ae specifically, 

for any nodé a ina BL-graph ¢ oy we! ie ne with a the pub- 

graph of G whose nodes and arcs sare accessible £ from a. This 


Faery 


subgraph | isa | BL-graph with a as ite root node; we call it 
the object of a. 


If there is a directed parr saahags one node of a Burgrere 


to another node). hen ‘the eaccnd node is called a “descendant 


of the first node. Ul nodes inva: BL-graph are daséehdante 


of some root node. A node from which no arcs emerge is 


a 


called a leaf node, An elementary object. attached to a leaf 
node is called the value of that node. If there is an arc. 
from a node a to another node: e, then 6 is called a com~ 
ponent of a, and the object of B is suliea’ a component _ of 
the object of a. otiponsnts are named by the selectors on 
the arcs leading into them. SS eh Aiton ia coapenent of 
two distinct objects, it is said to be shared patween:. them. 
Nodes in a BL~object are denoted by pathnanes oA oe 
for a node is a sequence of selectors labeling : a directed 
path to that node from the root node. I€ ‘the object of a . 
node is shared, then the node will have distinct pathnames.. 
The property of sharing is of major significance; we. will 


have mich to say about it. 


We will be saving Hoses use of pictorial ie ecenrac ‘ 
tions of BL-objects. An elementary object is drawn as an 
encircled value ious 2-1el). 
For a general BL-object, the 
nodes are iesiwn as heavy dots. 


The root node is at the top. Pig. 2. 1-1. Gangle 
ae . gmhenentaxy ebregte 


Arcs emeed=}e from a node are 


drawn downwards from a horizontal line ae to ne none. 


Selectors are written across the arcs that. they label. If a 


CBRE GELS RR EH eS Rersic Sees o 
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“gelector is a string, we do not enclose it in quotes. Elem- 


ehtary objects attached ‘ root cpaee “hang downwards from 


them.” ‘Thus our ‘pictorial conventions for. BL-objects differ, 


slightly €rom those used in “Denn ‘711. 


‘Sample BL-objects Bre | Pictured An figur es. 2.1-2 and oy 


aE Ie ea 


ee Sea Halon 


2. 1-3. _ The am at figure 2. 1-2 has three. gomponents, 


wey ly dela or Thee ‘ane 


.& 


named k, ¢ and a, The c-compon- 
vent is empty, . The k-component. 

has two companents, both of. - 

_ which are, leag, nodes. The leaf 
. node with value, 9. has pathname 
kK.c. The leaf node with value 

Fig. 2.1-2. A sample 

BL-object _ cae is paneced. patweer noses k 


faa rf ae 


“ane a and has path- 


names ei a and a -6. ay 
LT: ; = ¢ fs cos 
‘figure | 2. a a the, Ob-— 


ject with value. i. 6 is. 
aye i 
shared between the. Ob- 


jects 8. -b and 8 and 
“has Sathcaues 8.b.5 


Pye 


and sean ‘The object i: 


| Fig. 2.1-3) ‘A sample BL~ob ject} 


aif save eft 2807Ds 
Ries oe of) nodé e is shared 
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between the object of the root node and. the object C.vs 
Since the node c is a descendant of itself, it has infin-.. 
itely many pathnames c, Co¥2e CoV. 2.y-2, Coy. 2.¥.2-y-2, and 
so on. The path joining this node to itself is a. directed 


cycle. 


A basic difference between out: BL-graphs. and the graphs 
of {Denn 71] is that Dennis does not allow. directed cycles 
in his objects. Cyeles seem to impair the management of — 
storage and the handling. of paralleliam in computation. 
However, cycles occur in many of the. structures we shall be 
modeling. Moreover, they are difficult .to detect and re- 
move (see [Amer 72] Gols. este Malate cevthe Soublane oe: 


cycles). We-shall therefore not rule out cycles here. 


We follow [Denn 71] in giving the structure of a BL- 
object which represents a state of the interpreter. An | 
interpreter state is a BL~object having three components as 
follows: 

(1) The universe~component models system-resident in- 
formation, both data and procedures. Generally speaking, 
this Tyeomacice is independent of which computations are. 
currently andive omton far various computations have pro- 


gressed., 


(2) The locai-structure-component of an interpreter 


state has aS components a series of activation records for 
the various procedures being interpreted ‘in: the system. 
These: components are called local structures; there is one 
local structure for each activation of each base language 
procedure. A local structure represents the environment for 
its activation, primarily identifiers ané their associated 
values. Thue the local+structure ‘component of-an inter- 
preter state records the progress of computations by model- 
ing their changing environments. . 

(3) The contra@l-companent ‘has .as components a number of 
sites of agtivity, which indicate for each current compu- 
tation the next inatruction to be executed, ‘the appropriate 


environment (local structure) for the .cqmput 


tion, and other 


information. 


We shall not go into the details here of representing 
the universe- and control- components of interpreter states. 
The interested .re@eder can consult the Appendix for that kind 
information. We.will be. dealing almost exelusively with 
local structures .in the remainder of this chapter: In the 
next section, we describe the action’ © of a ntimber of 


primitive BL instructions, 
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2.2. Base Language Instructions 


We introduce‘the primitive instructions of BL, which * 
define state transitions of the interpreter fn “due modei °° 
Each ‘BL instruction executed by the interpreter ‘belongs to 
some procedure written isBt: and is interpested during an’ ” 
activation of the procedure. We call, the. logal, etruature 


corresponding to this activation the current local structure 


(c.1.s.) for the instruction... * 


A BL instruction consists of an. . “pper= ee 


ation code and up >to” three > opeyenas. | The 7 


operation. code .. is underlined. Most. of the oppradae of, 
the various instructions7are sedectors, (which are e frequently 
used to. denote names of components of the Foot node “of ‘the. i 
c.l.s. We reserve the jetters x, y, and z for selector 


names used in thig fashion. - fas 


We shall give informal descriptions of the ‘effects of 


BL instructions, accompanied by sample "before" and after" 


diagrams of the ocd. 8. Rh more formal definition ; of ‘Chawe: 
: mfyeret. ceeeriiico arte O06 
instructions may be found | in the Appendix. | 
Se eee hes fy fteghsch ae ot PATS! 


‘Bach instruction is ‘donigned | oe perform : a specific eee 


function in changing | the c. a; 8. This 28 called the. rimazy - 


7 ? 
ee RUG 
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role (or, more simply, the role) af the instruction, and de+ 
pends ‘on certain eenditions being fulfilled (e:g. the pres- 


ence or absence of specific compenests. in the c. da = ays ‘The! 


effect ef an instruction when. such: eonditians do not hold is_ 


called a. sybs. 


| Se ade cia deat acd Minas 

| ponent ih the c.l.s. Provided 
that: the c.t.s. has no x-component, 

“the piimary: role:of the instruc- 
tion. preahe x is to add one. 
(€iewnike: 2.261) inden thetic 
componenk: wil be. an empty: leat: 


“2, 2e1. . role of 7 


nedes ££: the cil.s.. already has 


. an x-componants then: the in- 
struction create x has a subsidiary effect: of changing the 
are with selector x from the root node. to point to a newly . 
allocated node. For this subeffegt the former. Jecompanent 
node wild 3 remain a as part of the c. +1. 8. nly. if it. was: shared 
with some other: node. “Figures: 2. and | through 2. 2—4 Hies- 
trate subeffects of the dnakrucetive Seente x an its ine 


terplay with the sharing Property. ‘Portions of a eae ales 


. enclosed in dotted lines are no longer part of the c. L, 8. 


Fg TS NN EA TR ETS 
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and can be thought of as garbage-collected. | 


Fig. 2.2-2. A subeffect «| Pig. 2.2-3. a subeffect 
of create x >) gfe s Greate ng EE : 


Fig. 2.2-4..A subeffect © ics 2.2-5. Role of — 
of _greate x glear x eS 


Fig. 2.2+6. Role of | Pig. 22347. A subeffect _ 
clear x | of  glear x . 


ee Seer ee PSL ie wee Bo ceo eo RE ws oe 


-30= 
The clear instruction is used to make a node empty: 
clear x detaches whatever hangs downward from the node x; 
leaving x with an empty value. The old value of x is lost. 
- even-it it wan shaved with some other néde. piguces 2.2-5 
, and 2.2-6 illustate the role of glear x. If there is no 
__x-colmponent in.the.c.l.s., clear-x - acts like create x: 


and generates one (fig. 2.2-7). 


oa 


The delete instruction removes arcs from the c.1.s. 


The arc from the root node to the node x is removed by: the 


instruction delete x (figs. 2.2-8 and 2.3«8). The arc 


Figx 2.2-8. Role of 
delete x 


Fig. 2.2-9.' Role of 
delete x ._ 


‘with selector m from the node x is removed by the two- 
‘@perand form delete x,m (figs. 2.2~10 and 2.2-11). If 
van arc to be removed does not exist, then the subeffect of 


the delete instruction is that no action be’ taken. 


i 


men te 


Fig. 2.2-10.. Role of oo ole of 
' delete x,m delete x,m 


‘the const instruction is used to cceanh dolenentacy ob- 
jects to nodes. If v is any elementary object, then “ 
const v,x causes the value v to be attached to the node: x. 
The old value of x, if any, iedcet. elgure 2.218 ilius- 
trates the role of the instruction const 5,x (where x is 
a leaf node), and figure 2.2-13 shows a subeffect of the 


same instruction (for the case when x is not a leaf node). 


Fig. 2.2-12. Role of “Fig. 2.2-13. Subeffect of 
const 5,x — const. 5.x ; 


wend gee oe rpm ogttge ot Sed itt ette chen Bat odo eam, SER Bo ci Set neg aaaee ete Be # aed! He eek. be i Bae Arcee reer Seg Re atine « Se 
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Arithmetic instructions such .as. add, suptr, mult and 


div are used to manipulate elementary values. For sharin 
: | the instruction gdd x, y2 

adds the values atpached to 
“nodes asa y and places the’ sum 


| in node e (figure 2:2-14) . re 
Fig. 2.2-14. Role of] | 


aad x.ys8 is an errer to attempt to ex- 


ecute an arithmetic instruction 


if one . of the first two eperens nodes oe to exist. or con= 


tains an Amproper value (not a leat node or empty or wrong 


type of ‘elementary object) . We leave the effect of such an 


attempt undefined. 


- 


The Jink instruction is used to initiate, sharing be- 
tween nodes. The instruction link x,n,y -cauees the node 


y to become the n-component of x (so that y will be shared 


Fig. 2.215. Role oT _ Fig, 2.2-16. Role of — 
_ dink wmy lt ee : 
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between the node x and the root pede)». ‘This, 38 ogne . by. add- 


ang an arc with selector n ashen node x to node Y-. Figures 


POM IN - 


2. 2- -15 and 2: 2-16 ‘illustrate the role oF. the. | instruction | 


Link X,n,y. te x already has an x-component or ig a 4 teas 


Oo: dae, yo 


node with some elementary value, then the subeffect of the. 


sogdtieiss 


same instruction causes the old value of x ad be Jost (figs. 
“*4, 4 fb ue /Aohed ® 


2.2-17 and 2. 2-18) . . The nodes for x and y mast ‘be present 


ASOT ESSN 
ate me sych Ree nf BOE 


or else the instruction | is /idlegal. 


Lae (2.2-17. _Subes tect! 


The select instruction sean’ a Aual FREPORS Ifa 


node x has an n-component, then the instruction sei Se RiP 


Peewee SF 4 ft} Ene abe bod 


"aes the “nccomponent of : x the y-component of fhe, root node 


rhyers rr HG warren” 


(so. that it can now be "addressed" ‘bar POEENer Le instruc-, rn 
es (10: 


tions) . In this manner a BL “procedure may gain RCCORS Pas 
Ps “EEL OTB Tense Tae 


arbitrary nodes of ac. ke 8. 1 x has no n-component, then. 
Be ny ak 7 


the instruction select x,n ny | generates one first, then, 
igeles it the y-component of the root node. This is the 
principal way to construct BL-objects, ice: by using the 
select instruction to add on conboti ents: These two roles of 
the weiect instruction are Reciictea in ae 2.2-19 and | 
2.220, respectively. The root node may or may not have a 
y~component prior to the siesition-o# select x,n,y. If it 


does, then the value is lost unless it was shared. 


Figs, 2. 2-80. 2nd role of 
Select x.n-y 


“Fig. 2.2<19. lst role of 
select x,n,y - 


The apply instruction provides for thie activation of BL 
procedures. Let the p-component of the c.1.s. represent the 
BL code for some procedure (i. e. be a ‘procedure eenae cure): 
Then | the. instruction apply p,x activates thie procedure 
in the following anher? First, a new, empty. local eSTNc 


ture is created. The x-component of the cuts s. is “then made 


the $par-component (parameter linkage) for the new local 


structure (we refer to the BL-object x as an argument struc- 


ture). Finally, control is passed to a new site of activ- 


ity. This means that the newly-created local structure he- 
comes the c.1.s. and the old site of activity is made dor~ 
mant. The interpreter will now execute instructions from 


the procedure p until it is told to return. | 


The return instruction provides for termination of the 
execution of a BL procedure and for return, to. the calling. 
procedure. Upon execution of a return instruction, the 
c.l.s. is deleted. All its saan naaes vanrene The Parpmeter 


linkage, since it | “gharee’ with the argument. structure of 


cay lt 


the invoking procedure’ s local structure, remains: Control 


is returned to the. dormant site of activity for the invoking 


‘procedure, and its local atruceudé: becdthes the“hew'c.l.s. 


The invoking procedure resumes’ from where it left off. _ 
In order to invoke a procedure, i must be represented 
as a component of the aw: The move e instruction makes 
data in the tiniverse availablé #or-invodation asa BL pro- 
cedure. We will not have oecasion to“use this instruction 


here; further details ‘are found in the Appendix. 


The instructions of a BL protedure are labeled with 


Ree Se eae Sa 
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natura] numbers; execution of a Bt procedure consists of the 
: ideaaelve execution of its instructions in sequence accoras 
ing to the numbers labeling them. ‘The remaining BL instruc- 
tions provide tor changes in the enero eaccence.. Each of 
them has as one of its operands a label 4 which must be a 
natural number labeling some instruction of the picceaute 


currently being executed. 


The instruction goto 4 transfers contrél to the 
instruction in the current procedure whose label is the nat- 


ural number 4. re erg 


The instruction elem? xh tests whether the x-com~ 
ponent in the c. is 8. is a leaf node (elenentary object). If 


not, control passes to instruction number he 


The instruction empty? x,4 checks whether the x- 
component of the c.1.s. is an empty leaf node (i.e. no com- 
ponents and no elementary value). If not empty, control 


ceanaters to instruction number £. 


The instruction nonempty? x,4 performs the same 
test as the corresponding empty? instruction, but control 


passes to 4 if the x-component is empty. 


The instruction eq? x,yYe4 looks at the x- and y- 


=395 


components of the c.l.s. Both must be leaf nodes, or else 
the effect of this instruction is undefined. These nodes — 
are checked to see if they have the same elementary value. 
If the test fails (i.e. their values are not equal), then, 


control passes to ¢£. 


The instruction hag? x,m,4£ checks whether the .x- 
component object of the c.l.s. has an m=component. If not, 


control passes to 4. 


The instruction same? x,y,4 checks whether ' the x- 


and y~components of the c.l.s. share the same node. If not, 


i.e. they are distinct nodes, control passes to ¢. 
In all the ahove conditional instructions, if the 
c.l.s. fails to have a component indicated by some operand, 


then the effect is undefined. 


- Other conditional instructions Siuissue to ene above 
ones can be defined (e.g. teating whether one elenen tary 
value is less than another). We will have no need here for 
auch saad tional tnatructicna: a oe 

| pinaliy: we discuSs one more instruction that will be 
needed. Given a BL object, we will ane be abis to 


access each of its components, without knowing beforehand 
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the names of the selectors. The getc instruction serves 
this purpose. Successive executions of the same instruction 
getc x,i,4 extract successive components of the x-compon- 
ent of the c.1,.s8. by causing the i-component of the c.l.s. 
‘to assume as its successive values the selectors on the arcs 
leading from the node x. No component will be extracted 
more than once, and control passes to g when no more com- 


ponents of x remain to be accessed. 


2.3. Programming Conventions for BL 


In this section we introduce a few programming conven- 
tions which will make BL procedures easier to write and un- 
derstand. We can view BL as the machine language for a 
hypothetical computer. Our Sepenniais are then similar to 


the programming features provided by a macro-assembler. 


Although individual instructions in a BL procedure are 
labeled by natural numbers, 
we shall use symbolic labels. 
For example, suppose that x 
and y denote leaf nodes in 


the c.l.s. Then the BL code 


Fig. 2.3-l1. Use of 
symbolic labels in BL 


of figure 2.3-1 places the 
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string value "yes" in the node ans. if .the values of x and y 


are equal, "no" if they aren't. 


The nodes addressed by operands.in the BL instructions 

must - direct components of the, ract node of the c.1.8, 

With the select instruction, we can access nodes further. 
down in the c.1.g... For instance, sup- 

_ pose we wish to change the value 3 in 
figure 2.3-2.jnto. the value 4, This is 
done by the const instruction, but..in 

| order to. access the proper node, we - 
must use the select instruction. thres 


times. In the, BL code that. performs 


our task (figure 2. a43iy the Fesgrved 


. Belecter Step acts as a "temp 


orary variable. Py | being: a 


x,b, $temp 
select $temp,d,$temp » dotted pathnane convention 


select $temp,e,$temp to Laan aed SRpropeiace: ‘nodes, 


lady 3 we can, anbrevinte this BL code 


Fig. 2.3~-3. BL code 
to: access a node: 


as the single instruction 


const t.4, Xbd.es- This ean be 
viewed as a _pacroninstrmetion Wiel. aundnelén, Gicek the. re- 


euieee: select instructions, Alternatively. we can, look at 


Pesca rN a) 


eS Ea RRO Se bag See oS ne te oo ar tay inant a elaine 
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this convention as extending “addressability" to arbitrary 


nodes in the c.l.s. 


We will make frequerit use of a macro~subétitution aa 
ability, which: i# provided by a “** ouevention If zisa 
_ ‘lewf node containing some elementary valve, then *z denotes 
this @lemetitary value. for example, in the c.l.s. of figure 
2.3-2, “2 denotes the value 6. the ‘abbreviation’ const *z,y 
specifies the same transition as the instruction const t 6, y 
when the’¢.1.%. is in. thie state. “tn the c.l.s. ef: figute- 
2.3=4, the leaf node with value 2 can 
be ‘addresséa ‘by any of the forms Xa, 
 *eZ, oFy.a, or fy. “Ra. while the. 
value 2 itselg,can be denoted by any of 


the forms *(x.a), *(x.*z), *(*y,a), 


| Fig. 2.34. To er #(#y.e2) 5 As a third example, the 
BL code: of figure. 2 375, sets 

Acca: - gete’ © et leees all the Spaiitdts of the db- 
onset 0, x82 P| ject. x 0. sere. : “Wote that the 


ke loop leaf node. i. containe as. suc- 


eeoe 


Heselve values the names of 


the selectors ‘from x. Thus 


the dotted pathname x.*i refers to the successive com- 


l= 


ponent nodes of x. 


We now define several macros for BL to denote commonly 


per formed functions. The .setl macro (set up socal © 


enictdes) is used £0 set up new ‘components. in the, Se de 3. 


Figure 2.3-6 shows the deena: the ..setl mince: arid 


figure 2.3-7 gives an example of its effect. — 


.setl (x1,...,xn) 


create xl 


ereate xn 


Big. 2.3-6. Expan- [| Fig. 2.3-7. Effect of 
sion of .setl macro | Betl (xy)... 


wg 


“ante remaining macros. we will | use deal with “Linkage 1 be- 


tween BL procedures. We first do tine: a Sorccaauee: iokuve: to 


be a BL-object with two components. The Stexggpmponent 
contains BL text of a precedure, apd the $env-component con-~ 
tains references: to the global variables named in the pro- 


cedure. (Note ‘that ngu is a legal cbaractér. in BL. ) 
The .call macro eneehde into BL code to packs a pro- 
cedure. In the definition in figure 2. a8. the node R must 


be a procedure closure, and al, ... , an are selectors 


te ce la «SaaS ge bteehe aBe AR 's So Mi eh RA, oh peers eR Oo 2 ic MENT roe co fi Raat ad eens me Sh Be Ee I 
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leading to the cama Tashi may be arbitrary ag a eck 


Figure 2. 3-9 gives an ex- 


yehery 


Fahy ea an ample of the invocation n of 


* ging a PINE Os gees procedure p having a 
tet Gee age ee 
Sarg, $gleb, “piven single global reference Ws 
$ arg, - Lal : 
the ‘procedure p te called 


with arguments x oud ia 
he. "olde: ho." ie the 


i 
fi eeenrl pocal structure of ‘the in- 
Fig. 2.3-8. “Expetaion of . 
the .call macro voking procedure, .and the 


: 7 tne. Ake 8% om the neal 
structure of the called. ‘procedure ‘a ‘The “etter” ~ptoturé 
shows both the ofa. cc. i. 8. bc the new c ekg 8. when control is 


passed | to the procedure Pe 


Pig. 2.3-8. Effect of call p, (ey) eit a 
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The .getp macro (get © perepaters) serves to Bane: the 


format parameters of a . procedure ‘testhe actual arguments 


iad 
a 


with which | tt was invoked. the -getg Saha (get . globais) 
makes the global variables named anda proeeduée accessible 
in its body. These. two macros are » defined’ in figures 


2. 3-10 and 2.3-11. 


-getp (xl,...,xn) 2 88ts. ee 


select $pat,1,xl fs select. SPR Sglob, x, Leh 


. 
. 


Select Spar.$glob,xn,xn 


select S$par,n,xn 


Fig. 2.3-10. Expansion 
of the .getp macro 


Fig. 2,3-ll1. Expansion 
of the .getg macro 


The first actions a procedure normally performs when 
given control are the retrieval of parameters and global 
variables (using the .getp and .getg macros respective- 
ly). Figure 2.3-12 is a "continuation" of figure 2.3-9, 
showing both ¢.1l.s.'s after the invoked procedure Pp executes 


the two macros .getp (u,v) and .getg (w). 


With the BL programming conventions that have been de~- 
fined here, we are now ready to use BL as the language of 


our semantic model. 


+ ve : Seige Hi coh ney tate SER Seeeqniey cto ae ee PRET ate ye SE iin are Dos. 
sa <4 eh a en Sos SENS tay ces Sabigesiae seis omc apse Bisa oc rae Re re 
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Fig. 2.3-12. State of the two c.l.s.'s after procedure 
p executes the matres .getp (u,v) and .getg (w) — 
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Chapter 3 


STRUCTURES, POINTERS AND SHARING 


3.1. Mini-Languages 


In this chapter we present a series of mini-languages 
which treat the issues of structures, pointers and sharing. 
The progression of mini-languages is hierarchical in that it 
starts from a few basic concepts and proceeds outward by - 
extension. Wand Siensidee 6 is the "kernel" language, iso~ 
lating the notions of variables, values and assignment. 
These basic concepts form the core for our domain of dis— 
course. Mini-Language 1 is a direct extension of Mini- 
Language 0, sdaing: 26 it penetra values and the sotions 
of construction of structured objects aya @election Of .com- 
ponents from structures. Mini-Language 2 extends Mini- 
Language 1 by including pointers and the two Sper ae tone of 
building and following pointers. Pinally, Mini<Language 3 
treats the idea of sharing of components between objects. 

By revising the concept of structured Vitus fonda in Mini- 
Language 1, the notions relating to poinears ace subsumed in 


Mini-Language 3 by notions relating to sharing. 


Each mini~language is treated in a separate section of 
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this chapter. In each section, ie tigate discuss in general 
terms the dencepts addressed by the gini-ianguase under con- 
sideration. New terminology is introduced, and we describe 
the relation to previous and/or succeeding mini-languages. 
We then supply a BNF-style syntax together with a descrip~ 
tion of the syntactic classes and what they represent. The 
semantics of the mini-language is stated informally, a la 
ALGOL 60. we then formalize the semantics by giving samples 
of rules for translation from the mini~language into the 
base language BL. Each section is concluded by @ “movie” 
illustrating the interpretation of the BL program peosuces 


by the translator from a sample program in the mini- ~language. 


ue final section of this chapter applies these mini-~ 
languages to the task of describing the data structuring 
semantics of "real-world" programming languages. The lan- 


guages PAL, QUEST and SNOBOL4 are used as examples. 


Mini-Language 0 (ML-0) is the foundation upon which we 
build our mini-language setup. In introducing the concepts, 
of value, location and assignment, ML-O serves as a kernel 


for our set of mini-languages. ‘The notions of structures, 
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pointers and sharing will emerge as extensions to ML~O in 


succeeding mini-languages. 


All our mini~languages, starting with MLr0, operate a 
within the conceptual world of values,,atored. in locations» 
which we call cells. The relationship between a cell and 
the value stored in it is called the contents mapping. ~ 
cell with no value stored in te is said oe be empty and has 
no contents. We are concerned here with ‘the fundamental, op- 
eration of assignment, which is “aued to change ‘the contents 
mapping. In fact, the. entire ‘purpose in creating M0 was 
to isolate the concept of assignment By placing it in tee 
minimal and austere a set of surroundings: as possible. ' ‘This 
notion of aeaijgnmant will remain, unchanged in the remaining 
mini-~languages of this chaptex. ° The assignment statements 
of these languages will be “consistent” extensions of what 


we define in this section. 


Another important contept we deal with here is the . 
notion of binding. Each ident?#iér'in’ an’ MtSo ‘program is - 
associated with a unique and distinet cell. This! assdcia~ 
tion is ‘called the binding of an ideneserei®. The Value of 
an identifier will be the contents of the cell to which it 


is bound. (An identifier bound’ to an ‘empty cell has no 


apes agp ene ae a, orto oR ten fe often eae oe ect ee ea Ee a 
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value.) Unlike the contents mapping, the binding relation 
remains invariant throughout the execution of an ML~O pro- 
gram: This’ irivatiance is a property nOt only of ML~0, but 


of all the mint<lariguages in this ‘ttests. 


Syntax of ML-O 


We give a ‘BNF-style syntax for ML~O. ,Tnformal use is: 
made of the ellipsis ee to sastoute repetition. Two 
syntactic « classes are prinitive: {integer ) . denotes fee 
constants, and (identifier) denotes aiphanuneric strings 


starting with a peErer 


(program) ie (assignment) Fo eee ; (assignment) 
(assignments: (destination) + je . 


(expreseioh) .i¢ {destiretion) f° (yetieratory | nil 
(déstination) ::= . (identifier). 7 
(generator) — is (integer) 


Description 

To understand assignment, we explain -the syntactic 
classes relating. to values and. cells... A (generator) is a 
piece of program text denoting a. value... All: values: in Mb-0— 
are Aneageres subsequent mini—languages. dnelude other. types 
of valnes as well. A (destination). is,a piace. of program. 


text referring to a cell; (destination)s dn ML-~O0 are simply 
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{identifier)s, i.e. variable names. The reserved WORE nil 
will be used to signify empty aetia: An (expression) isa 
piece pe Breeton text which Presale a value. The genantic 
description nelow hisciebes evaluation. of (expression)s in 


ML~O. 


An ML-O pesveuns is simply a, sequence of {assignment)s, 
each of which consists of a (destination) and an (expression). 
The basic meaning of an (assignment) is 66. catiée “the value 
yielded by the (expression) to be atocea ante the cell re- 


ferred to by the (destination). 
Semantics of ML-O (informal 


The notions we have aaae introduced will now ne made 
more p PEGEIES We give the semantics. associated with each 
significant syntactic class of ML-0 (now as a description in 
English, later more esrca tig: via <eanmineion ‘nts BL). 

(1) (program)s: The execution of an ML-O (program) 
doneiete of two steps. First Hina gech tidentd fiers. ce~ 
curring in the (program) to a Sistine: ouses cell: Then 
execute all of the (assignment)s sequentially, left to 
right. This rule giving semantics of (program)s will remain 


intact for all the subsequent mini-languages in this chapter. 


+ RE Leer gee 
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(2) (assignments: The écacution of an (assignment) 
ae ee ee na Sect 
consists of three steps -- 
(1) Identify the cell referred to by the 


(4estination) ‘on-the-beft-hand side of the 
(assignment) (see rule (3) below). 


(ii) Obtain the value yielded by the (expression) | 
on the right-hand side (see rule (4) below). 


(iii) Make the value from step (ii) the new contents 
of the cell from step (i). 


Thus the effect of executing an (assignment) is a change in 
the contents mapping. This rule, like rule (1), will govern 


the semantics of the remaining mini~languages. 


(3) 


bound to this (identifier). This binding is detornined at 


the beginning of program exesution; as we have ) already said, 


it remains constant throughout execution. 


(4) (expression)s: There are three varieties of 
(esptaaeton\. in MEO. We descrite’their senantics in rules 
(5), (6) and (7) below. poe ee = we 

(5) nil: The special symbol nilindicates the absence 
of a value. Any time we are directed to store in some cell 
the value yielded by an (expression) which is nil, this 


means to make the cell empty. All of our mini-languages 


5 Tee 
treat nil in precisely this manner. 


(6) 


(destination) occurs: as an instance. of. an <expression) (in 
ML-O, this means on the righthand side of an (assignment)), 
it yields the value contained in the cell to which it refers 
(see rule (3) above). If this cell igcehpeys the. 
(expression) is treated like nil (see rule. (5) above). This 
semantic rule (known elsewhere as "dereferencing"} will heid 
verbatim for all our mini-languages. 

(7) (generator)s: A (generator) in’MUSO ‘is an + 
(integer), which is the decimal réepréséntation of some 
integer value. it is thia value which is yielded by the 


(generator). 


The above sevén rules constitute our informal descrip- 


tion of the semantics of ML-O. 


BL Representation 

The semantic rules we just gave are a bit long-winded 
and imprecise. A rigorous description of the semantics of 
ML-O can be obtained by "translating" these rules into BL. 
instruction sequences. Before doing this, we discuss our. 


basic conventions for representing mini-language programs in 
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‘the base language model. To each program in one ‘of. our 
mini-languages,: there.is-a single oda. wtructuxe. The 
- cells used by the program are represented by nodes in the 
lowal structure. For each identifier occurring in the pro- 
gram, there is a cbrrespondingly. named. component: of the 
local structure. which. gives its’ binding. -In’ other words, 
the cell bound to an identifier. x will be the x-component 
smode of the local structure. The contents of this cell is 
the object of its node. Thus the BL‘ translation of any . 
program in one of our mini-languages will have a "prologue" 
to bind the identifiers of the program. For. example, the 
prologue for an ML=C (program) whose ,(identifier)s are x, y 
afd z will be the BL macro-instruction .setl (x,y,2),, which 
expands into the sequence = Sree *) create yt Greate Zz, 
creating nodes for the cells bound to thas (identifiers. 
Integer values are gepresented in . the base ne eaede model by 
elementary objects of type integer. | | 

As for the translation rules themselves, we give sample 
ML-0 statements © ‘(aaaignment)a) and the BL code they are 
translated into. ‘Each example is  fildetrated: by one or two 
“before and after" pictures howling the Ghange ‘the statement 


makes in the’ local structure. Although our examples are 
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meant to be indicative rather than exhaustive, they should 
be more than sufficient to give the reader a complete pic- 


ture of the rules for translation from ML-O into BL. 


There are essentially three kinds of (assignment )s 
in ML-O: 

(1) (identifier) © nil 
e.g. x nil is tranglated 
into the BL code | EX 

| Fig. 3.2-1. Effect of 


clear x (fig. 3.2=1). {the ML-0 (assignment) 
x ¢ nil 


(2) (identifier) - (anteger) 
e.g. ye 2 is: translated into. the BL: ‘tode 


const 2,y (figs. 3.22 and 3.23). 


Fig. 3.2-3. Effect of | 
¥. & 2.5. jin MLO. 


Fig. 3.2-2. Effect of 
ye 2 in ML-O . 


(3), Aecentaese) + (identifier) 
e.g. yex is translated one. hedge ae ore 


Sat RRO. This eede invokes a. BL ‘procedure named 


Pin Wige temrmag HORSE Si EE Tg ots Sn? aE So A opener eaten ails aS sian teen tir vet anor any NOT ee vin sina onl tay RMS gee PSY RHE eT ee no 
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assign, which performs the operation specified by the ML~O 
(assignment). “The definition of ra procedure aseignd is 
shown in “figure” 3. 2-4, and two examples of the ML-0 


(assignment) y + x “ete pletured-it ‘ffyaré 352-5. 


_assignQ: -getp 


Figure 3.24. 
Definition of the BL 
procedure asagign0.. 


"Figs. 3.2-5. Effect of 
2 ton tee in ML-O | 


The three translation rules here give us a precise formul-_ 


ation» ‘for the Samentice of ML-0 in terms of the semantics | ‘of 


é 
fe tees 


the base Janguage model. 
. eee 
"We contlude this section by giving a sample ME-0 


(program) together with its BL trend Peteene: our exeupie ig. 
itt ,, Ae St 8 ee : 
accompaniad by a sequence of pictures forming a "movie" to 


illustrate the ghangins state of the ieee stracture as the 


Caren 
te 


program is interpreted, statement by statement. 
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; .setl (X,ye2) eae 
3: ‘const «3.x 0°22” 
x? 9: .@all assign0;'(x,y) 
3 aseignd « (ZX) 


4; const 4,z © 
- inet 


MN UK KM OK. 
Be, ee 
i 
F 


Mini-Language 1 (ML-1) adds the notion of data struc~ 


tures to the‘ fourdation”providéd py “W+0°° As we have said 


before, a structure ig’ a data object which consists of iridiv- 


caw oy 


ere 

idually senbaatnie component objects. There are two funda+ 
mental operations relating aivesely 65 this Gencape Os 
structures: (1) constriction ‘of a structured object whose 
components will be objects with, ‘gious: values, and . (2) seledc- 
tion of component objects ‘from a structure. MU=1 provides 
for these operations while retaining intact the concepts and 
mechanisms of ML~O. In particular, is cations ce cells, 
values, contents, binding and.assignment are-exactly as — 
before, tee 

aaa ‘addition te the integae! vaiues found in ML-0, ML~1 
provides: « new class of structures. ‘A structured vane pila 
‘gists of a sequence. Of componerit values (which may be ae 
_egers or structures). To ‘store. away a ied ak Solet value; “we 
require one cell for the structure, and also separate cells 
to. noid the values of its components. This requizenent is a 
‘departure: from ML-O, ‘in which all ‘cells in use are bound to 
~tdentifiers. Component ‘célis mat’: now be. handled ‘by some 
Kind of free-storage management technique.or.gell.aklo— 
cator. . 

‘In ML-1, a cell may assume successive values of diff- 


erent types (an integer one.moment and a structure the-next, 


or vice versa). There are no restrictions on what values 
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may be stored in which cells. There is a need, however, to 
detect references to nonexistent components of a structure. 
Such error-checking will have to be performed by the defin- 


ing interpreter. 


Syntax of ML-1 

There is a new primitive syntactic class here, namely 
(selector), which denotes alphanumeric strings together with 
integers. 


(program) 35 (assignment) ree ; (assignment) __ 
(assignment) ::= (destination) « (expression) 
(expression) ::= (destination) | (generator) | nil 


(destination) ::= (idéntifier) | (selection) 


(selection) 235 (selector) of (expression). 
{generator) ::= (integer) | (construction) 
(construction) ::= [ (field) ; (.. 3; ¢£4eId) ] 
(field) - ::= (selector) joeepembeteas 


Description 


Structures in ML-1 Been en ences of iia sane values. 
Each component in a structure has associated with at a 


{selector}. The selection operation gives individual access 


to the components of a structure by aaing the Vewledtatve to 
indicate the appropriate components. ~fhus, ‘for example, the 
(selection) aof x refers to the component of the struc- 


ture x having the (selector) named. "a". 
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‘The notion of (destination) «is extended in ML-1 to in- 
elude selections of component objects from structures. In 
particular, (selection)s may appear on both sides of 
iuesidement ye: This allows for selective updating of com- 
ponents of a structure. A {selection) occurs as an instance 
_ of a (destination) and refers to a component.cell for a 
structure. In this way, ML-1l preserves the ML~O association 
between (destination)s and cells. _ 

Also as in ML-O, distinct ‘(destination)s refer to dis 
tinct cells. There 1ésn6 sharing of data. | 

All values in ML-1 are created by instances of | 
(generator)s. A (ecdetnistions isa gieclal kind of 
(generator) provided by ML~1 ‘for building: structured values. 
Ina (construction), we simply supply (expreasion)s yield- 
ied values ZOF he ace sinaioas with the associated aad aa 
Bach component name/value pair is called a (field). Thus 
the two kinds pe {generator)s, namely Aanteger)s and 


(construction) s, produce the two ‘kinds of values in ML-1. 
Semantics o: -1, (info 


- As with ML-0, in order to lend precision to the notions 


wé have introduced, we give. an informal deseription of the 
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semantics associated with each significant syntactic class 


of ML-1l. 


(1) {program)s: The semantic rule for an ML-1 (program) 
is identical to rule (1) in the previous section for ML-0 


{program)s. 


(2) (assignment)s: ML-1 (assignment)s work by the same 
principles as in ML-0O, but there is.a new factor here. Sup- 
pose the value yielded by the (expression) on the right-hand 
side of an (assignment) is. some structure, Then new cells 
must be allocated to store the component values of this 
structure. The component cells are said to be subordinate 
to the cell for the structure ‘they belong to (i.e. to the 
cell referred to by the (destination) on the left-hand side 
of the PacaGsoneney i: Moreover, if a cell containing a 
structured value is assigned some Bete value, then the com- 
ponent cells subordinate to this cell are detached and left 
for the cell allocator to garbage-collect. Structured val- 
ues are copied on assignment, component by component (and 


recursively for structure-valued components) . 


(3) <destination}s: There are two kinds of 


{destination)s in ML-l1. (identifier)s are handled exactly 
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as in rule (3) for ML-O. We now discuss (selection)s. 


(4) (selection)s: A (selection) consists of a 
(selector) and an (expression). The value yielded by the 
(expression) (see rule (5) below) is determined. This 
value must be a structure, or the effect of the 
(selection) is undefined. Furthermore, this structure must 
have some component with the given (selector). Finally, 
this component must be stored in some component cell (which 
was allocated when the structured value was constructed). 
Then this component cell is the cell referred to 


by the (selection). 


(5) <expression)s: With respect to the three kinds of 
(expression)s in ML-1, the occurrence of the indicator nil 
or of a (destination) is treated exactly as in ML-O. As for 
(generator)s, the only aspect we need to explain here is the 


semantic rule for (construction)s. 


(6) (construction)s: A (construction) consists of a 
sequence of (field)s, each with a (selector) and an 
{expression). Each (field) represents a component with the 
indicated (selector) and with value yielded by the 


(expression). The rule for interpretation of a (field) 


“(fiela)s sequentially,. seft to, Biahk, Fase 8 


This results in a series. of | 
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PCORS RES of EnEee. ayers ~- 


See tisae, SHES Ae ee 3 ips te roe ne, “pi aed 6 Gee gy Bans OE Sree eet 


“(G) Evaluate me Serer ee etn) 


— (42) Allocate. a new eee = store ‘the gon from 


, (iii) Aagociane Aicauigiy: saps a 
(and the value it now contains) with the 
(selector, QE the <field. ey nore: 

ies |. BHQVE»: 


The semantic rule for a (construct 


_Ponent cells and acgesgible by, (gelechor)6..OF...A%,We, better 


know it, a structure, . There, is. one additional. restriction 
on (construction)s: the (selector)s of its (field}s, myst.,be 


scoala or else such a daccitege heey sd ALlegal and has 


' 2 ge * Sey a ee Sfe eit coe et 
undefined Re etack: 
a 4 tf sz 2 
BL Representati ; : 
i) SE ce a ass engi sas ork ci aS + : Sai af $ 


We. represent: etenucturessinsRL+1 by BL<6bfeéte fs ‘Which 


the .roet node corresponds:-to: theseelk we btére ‘the structure 


in, and in which: the: avses:are:habeted withthe! (sélectorys 
of the structure and lead into nodeg dageetaniias the corr- 
esponding component cells. An axamgle .yashava already sean 
is the environment, Cleeal seryegure ; £AR 8 rah adenguage ~ 

program, which is a atructured value whnae .tgalecter)e axe 


Coee ers Ror ayay we  BMOE P Pere a ee 


aa <a 


the variables used in the program. Another example is the 
structure generated by the (construction) _ 
{ a:l; b:[ c:2; drnil ] 1, whose BL rep- 
resentation is pictured in fig. 3.31. 

A valid ML-1 (destination) corres-— 


ponds to a node addressable by a cdém- 


| | Fig. 3.3-1. 
pound pathname. Por instance, if the —  ‘IBL-object for 
fa structure 


truttured value of figure 3.3-1 is 
assigned to the (identifier) x, then the cell referred to by 
the (destination) cof bof x will be represented by the 
“node x.b.c. 

As with ML-O, a ML-1 (program) er (identifier)s are 
xl, ~.. , xn has in its BL translation the prstodus | 
»setl (xl,...,%xn). We now treat translation of various ML~1 
dassignment)s into BL, illustrating general translation 
techniques that can be readily applied to any M1-1°state- 


ment. The following cages are representative: 


(1) (identifier) + nil 
and (2) (identifier) + (integer) 
aré both handled exactly as in ML-0 by the respective BL 
primitives clear and const. Note that the action of these ~ 


BL instructions disconnects any subordinate component. cells 


that need to be detached. 


(3) (identifier) s (identifier) 
e.g. ye xX. This kind of ML—1 (assignment) poses a problem 
in translation when the source (expression) x has a struc- 
tured value. In that case, the structured value for x must 
be copied component by component. into y, creating new cells 
as required to hold new coupohenes we y-. This kind of 
action is illustrated 
in figure 3.2-2. we 
shall translate the 


(assignment) yex 


- asa call on a BL pro- 


Fig. 3.3-2. Sample effect of cedure named assignl, 
the ML~1 (assignment) y + x 


when x has structured value. ~ 


so the BL code for the 
statement ye x will 
be .call assignl, (x,y). The code for the BL. procedure 
assignl is shown in figure 3.33. If x is: empty. or has. an 
integer patie: then agsignl works like the assignO procedure 
which translates the ovauieddins duet: esa tgemeut): If x 


has a structured value, then for each component of x, we 


generate a corresponding component for y: (allocating a new 


cell) and call assignl recursively to give this. component 
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of y the proper value. Here, the parameter. u corresponds 


‘assignl: -getp (u,v) 
clear v 


nonempty? u,out 

elem? u,@truc 

const *u,v 

return 

.getg (assignl) 

gete — u,i,out 

-call > assign1, (u.*i,v.*4) 


loop 


Figure 3.3-3. Definition of the 
BL procedure assignl. 


to x, and the parameter v corresponds to y. 


(4) (identifier) + (selection) 
e.g. ye bot x. 
The pitfall here is that we 
must check to verify that. x 7 
indeed has a b=-component. 


The following BL code takes — 


care of this test: ees een: RELee Ot 
in ML-1l. 


has? x,b,error 


-call assignl, (x.b,y) - 
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The label "error" refers to some unspecified place we branch 


to if x has no b-component. 


(5) (selection) ¢ (identifier) 
e.g. cofaofyex =is translated into the BL code 


has? y,a,error 
has? y.a,c,error 


-call assignl, (x,y.a.c) (figure 3.3~5). 


(6) (identifier) ¢ (construction) 


e.g. y ¢« [ a:3; b:nil; c:x ] translates into 


const 3,y.a 
clear y.b 
-call assignl, (x,y.c) (figure 3.3-6). 


Fig. 3.3-6. Effect of 
y ¢ [ a:3; b:nil; c:x ] 


There is a subtle pitfall in these translations, Spec- 
ial care must be taken in translating (assignment)s in which 


the left-hand side and the right-hand side both refer to 


' has? y,b,error 


(assignment) bofyey into 
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cells in the same structure. Suppose, for example, that y 
has the structured value depicted in figure 3.967: Trans- 
lating the (assignment) bof y + y into the BL code 
} will not yield the correct re- 
.call assignl, (y,y.b) ¥ ; 
sults of figure 3.3-8. Instead, there would be a nontermin- . 
ating sequence of recursive calls of the procedure assignl 


(figure 3.3-9). We must therefore transiate the 


has? y,b,error 


call assignl, (y, $temp) 

.call assign1, ($temp,y.b) 

With this translation, the recursion terminates because we 
are not updating the structure! $tempiduring the process of 


recursively going through its comporients. 


‘For other cases of "overlapping" assignment, we adopt 
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similar translations. For example, we translate the 
(assignment): y eT asl; b:y ] into the BL code 


.call assignl, (y,$temp) 
clear y 
const l,y.a 


-call assignl, ($temp,y.b) ; 
and we translate y+ [,c:a of y } into 


has? y,a,error. 
clear $temp 

link $temp,q,y.a 
clear y 


-call assignl, ($temp.g,y.c). 
Note that in ML-1, the translator can detect any 
occurrences of these “overlapping” assignments and make the 


according adjustments. 
ML-1 Movie 
As in the previous section, we conclude with a movie . 


of a sample ML-1 (program) and its translation into BL. 


ML-1 ae 


etl (x,y) 


coe - . . eonst 44x 
y «+ [| a:2; b:x; e:nil J; = een - cave ene 


const 2,y.a 
-call assignl, (x,y.b) 


a60s 


BL 


y,a,error - 


assign, (y.a,x) 


y,a,error 
3,y.a 
assignl, (y,x) 


erear y 


-¥,a,error 


assigni, (x.a,y.1) . 


y.2 
¥.2.23 


>; 4,y.2.8 


y.2,error 


‘Yy.2,8,error | 


x,a,error 


“assignl, (x.a,y.2.8) 


.X,C, error 


assignl, (x,$temp) 


assignl, ($temp,x.c) 
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3.4. Mini-Language 2 -- Pointers 


Mini-Language 2 (ML-2) extends the concepts we have de- 
veloped and treats the notion of pointers (references). A 
pointer is a means by which one can indirectly access a cell 
and its contents. As with structures, there are two basic 
operations inherent in the concept of pointers: (1) crea- 
tion of a pointer value which refers to a given cell, and 


(2) accessing the cell a pointer "points" to. We wish to 


ae Me TES Op eee Some ba geo Veneer Aba ue Sere ERE eB TE ee at Shaeetyomeaimgemetrite ie patrons yoo es RS 
? 
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- provide’ for these eperettons: waiae greserving the ‘eoncepts 


and mechenteet that have already been developed in this 


chapter. 


| jue es a new class af pointer values. As 
with ML-1, cells can accommodate successive values of diff~ 
erent classes. We will not, however, allow indirect refer- 


‘ 


saa aa aac which are not. pointers. 


One respect in which the notion of painter differs £rom 


previous. concepts is that a pointer waiae contains ineoes 


fnation about the coll it refers to. Previous concepts of 


value had nothing to do with cells. We eheli, see some of: 


the difficulties caused by this éxtedeioe. 


In this section, we treat mu=2 as an eavedsion of ML~1. 
However, it is not necessary to include ‘atructures in ordee 
to hundle the new notion. of pointers, one could alterna- 
tively omit steauctures. from: ML~2 and wlew it as a direet 


extension to ML=0. 
enbak of Mac? 


The “boxed” - portion of the ML~2 syntax 5 is that part of 


4 


ML~2 that deals with structured values: and the basic oper- 


ease on nein. 
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(program) ::= (assignment) ; ... ; (assignment) 
(assignment) ::= (destination) ¢ ¢expression) 


(expression) ::= (destination) | (generator) | nil 


(destination) ::= (identifier) | ¢ (indirect) | | (selection) 


(indirect) val Resp nape son): 


(selection) 


(selector) of (expression) 


(generator) 225 integers | toointacs | <construction) 


(pointer) ptr (destination) 


{construction) ::= [ (field) 7 ... + (field) a 
(field) ' os: (selector) 


: (expression). 


Description 

There are two new syntactic Ci Seeee. in ML~ ~2. A 
(pointer), consisting of she symbol pie and a a (destination), 
specifies the creation. of a pointer value which will refer 
to the same cell as the (destination). The only way to 
build pointer values in ML-2 is by means of (pointer); we 
therefore classify the (pointer) syntaetieally as ‘an ‘in- 
stance of a (generator). An (indirect), consisting of the 
symbol val and a (pointer-valued): (expression), is ML~2's 
way of accessing the-cell referred to by ‘a pointer value. — 


As such, an (indirect). is a kind of (destination) . 


We have already seen all the other ML~-2 syntax classes. 


Semantics of ML-2 informal). 


Ail we need to give here are informal semantic rules 
corresponding to the two: new: syntactic classes. All the 
other semantic rules for ML-2 ace dcektieed to the: corres~ 


ponding sales? toe m6 or ML~-1. 


(1) (pointer)s: This kindof (expression) contains a 
(destination) and yields a pointes value which refers to the 


same cell as the (destination). 


(2) (indirect)s: An (indirect) eonesine an. (expression). 
The value yielded by the oa ickenntacned is determined. If it 
isn't a pointer, the (nairect) a undefined value. Other- 
wise the (indirect) apecifies. the. cell vereccéa. to by Hii 


pointer value. 


BL Representation 

Deciding.on a way, to represent pointer values in BL 
presents difficulties. In: most ¢converitional systems, point- 
er values are simply the numeric addresses of celis.. How~ 
ever, in the: base language. -model,: referendiny of cells is. 
symbolic. tie Shek ves ae ao ee tila peopiem 
is: to view a cell's pathname (i.e. sequence of selectors 


from the root node of the current local structure) as its 


Pie ac pe 


address. A pointer value would then be represented in the 
base language model by an elementary string value encoding 
the pathname of the cell pointed to. Under such a scheme, 
after executing the ML-2 instructions 

xX # 3; y+ ptr x; Ze yi we val y 
the environment would appear as in figure 


3.4-l. After the further instructions 


Z¢« xX; val y « ptr z 
are executed, the environment would then 
appear as in figure 3.4-2. Under sbeh a 
scheme, translation into BL would not be 


difficult. However, this approach breaks 


down in the presence of structures. For 
example, execution of the sequence of ML-2 instructions 
x «+ [ a:2 ]; y e ptra of x 
would result in y having as value the 
pathname "x.a" (figure 3.4~3). If we 
then execute the (assignment) x ¢ 3, 


x would no longer have an a-component; 


the cell containing the value 2 would 
therefore no longer have the pathname x.a and would hence 


be inaccessible through y. In other words, under this 


ahs 


scheme there is no way to provide for retention of cells 
referred to by pointers. The main conceptual weakness of 
this scheme ia that the address of a cell depends on a par- 
_ ticular hence access to it. Such a dependence is to be 
iaybiaed, | 

A second way to refer bs a cell is by directly linking 
to it, that is, sharing it. It ie: imperative that the 
pines have a separate cell for itself as well as the cell, 
at points to. othenies: after executing the ML-2 instruc+ 
tions x ~ 3; y & ptr ie | we would have a 7 | 
edituation’ as pictured in figure 3.4-4 in 
which the (assignment) ye 2 would err- 


oneously affect x (we want to access x 


through y only by use of the Piel ceoey. 

‘val y). To insure separate cells, we will make a pointer 

cere an: instance of a structure, where the cell pointed to 

will. be the sole component cell. rhus: | | 

the result of executing the instructions 
xe [ a:2 ]; y e ptr a of ms 


will be as in figure 3.4-5, and after the 


further instruction x ¢ 3, we see that 


the cell containing the value 2 is proper- 
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ly retained (figure 3.4-6). Note that we 
have adopted the reserved name "Sval" as. 
the selector for the single component of 


an ML~2 pointer value under our repre- 


sentation scheme (to avoid clashes with 


the (selector)s of ML-2 structures). 


Now that we have settled on a BL representation for 
pointer values, translation of ML*~2 into BL is straightfor- 


ward. We only need consider four new cases of (assignment)s: 


(1) (identifier) ¢ (pointer) 
e.g. y ¢ ptr x is translated into the BL code 
clear y 
link y,$val,x 

(2) (identifier) + (identifier) 
e.g. ye x is translated into the ‘invocation 
-call assign2, (x,y). Wceaveke definition, of the BL pro- 
cedure assign2 is shown in figure 3.4=-7. ‘The difference 
between assignl and assign? is that assign2 has additional 
code to handle Saaignmeneor pointer values, preventing us 
from attempting to copy the cetente oe a cats referred to 
by some pointer. An example of the assigning of a pointer 


value is depicted in figure 3.4-8. eh : ' 
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assign2: 


u,$val,struc 


v,$val,u.$val 


(assign2) 


loop: gate : u,i,out 
call assign2, fa.*i,;v.*i) 
loop... 


1 Set errs 


Figure 3.4-7. Definition of the 
BL procedure assign2.— ac 


Fig. 3.4-8.. Effact::of — 
the ML~2 (assignment) 

Yo * when » haga 

pointer value. 


gpd eked es 


(3) (identifiers + (indirect) 


e.g. Ze val y is translated’ into the BL code 
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has? y,$val,error 
-call assign2, (y.$val,z) 

(4) (indirect) ¢ (expression) 
e.g. val x « 3 is translated into the BL code 
has? x,Sval,error arn oe 
const 3,x.$val 

Using these translation schemes, it is easy to produce . 
BL code corresponding to-any ML-2 jprageen): However, the 
presence of "“dévéerlapping* assignments can no longer dlways. 
be detected by the translator. For example, in, the state _ 
depicted in figure. 3. 4-9,. we want the (assignment): 
b of y + val x to resuit in the state shown in figure 
3.4-10. The BL code > | 


has? y,b,error =... xs 7 
has? x,$val,error. 


-call assign2, (x.$val,-.._ 


. $temp) 
.call iteiond: ($temp, 
y-b) 
works properly, In | nafs : =o Paige 3,4-i0 
other words, the trans- « 6 4: | 


:% 


ner Bee produce BL code to perform extra + copying whenever 


inefficiency, since paper ee) eee a Ae an een event. 
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- M~-2 Movie | 


Link 
- has? 


Be 
-setl | (X,¥s2) 


 Glear x 


const 4,x.a — 


x,b,error 


‘clear y 


“ y $val,x.b 
gas. -¥.$val,exrror 


const 5,y-$val : . 
“has? y.$val,error 
-.eakt assign, ty $val, $temp) 
slear z bon 


-call assign2, (y,2.c) 
.eall. assign2, ($temp,z.d) 
z.e@,$val,2 

x, b,se¥ror 


const -6,x.b 
.call assign2, (z,x) 


3.5. Mini-Language 3 -- Sharing © 


So far in this chapter, w we have progressed through 
three mini-languages in developing our semantic Boge for. 
data structures: and po incene: Although ML-2 mandse8 i oF 
these concepts, there are some respects in which the design 
we so carefully built up becomes cumbersome and inetegant: 
In this section we shall look at geile OR the weakaeanes of 


ML~2 and sée how they reflect ‘a conceptual shortcoming in _ 
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our design. The mini-language ML-3 is devised to remedy 
these deficiencies. By revising the notion of structures, 
ML-3 becomes not only more powerful and efficient than ML-2, 
but conceptually simpler as well. In fact, the entire ap- 
paratus of pointers that was developed in the eee tous sec- 
tion is subsumed within the re-definition of structured 


value. 


The main difficulty with ML-2 emerges when we consider 
the way pointer values are represented in the base language 
model. This is admittedly a rather strange way to examine 
the merits of a language, namely in terms of a representa- 
tion decision with respect to a particular semantic model. 
But the base language model is special in that it was spe- 
cifically designed for the purpose of describing the con- 
cepts of sharing which we are studying. So it is perfectly 
valid to use insights provided by this model to aid in de- 
signing mini-languages which deal with data structures and 


sharing. 


In the last section, we chose to represent a pointer 
value in the base language model as a one-component struc- 
ture whose component cell is precisely the cell pointed to. 


In other words, pointer values are instances of structures 


ne 


whose components share with other data objects. It is this 
much — general concept severed data objects that con- 
cerns us in this section. The only kind of sharing provided 
in ML-2 is the pointer, sihieh is a structure having exactly 
one component cell, shared with some object. In the course of 
trying to model aspects of real-world programming languages 

in ML-2, this Vim tation becomes a stumbling: block: For 
example, the notion of ‘tuple in languages iike BASEL is that 
of a vector of addresses, 2g e, a structure with we arbitrary 
number of components sharing with” “other objects. In ML-2, 
this can be modeled only as a acrakeice ‘Viose components 
are pointers. These components, when represented in the 


base language model, take up an extra level of indireetion, 


which becomes a bit clumsy. 


To give a better treatment to this generalized notion 
of sharing, we vaviné our apie of structure. In ML~2, as 
in ML-1, the notion of structured values as being composed 
of components with declector is saad aries: does not. directly 
utilize the concept of cells. Celis are part of a a 
pointer values. What we've done in ML- 2 is represent, 


pointers like structures but use a waleraseut set ef rules to 


manipulate them. This conceptual distinction puts the two 
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notions -- structured values sa enter Seiten 22 almost at 
odds with each other in ML-2. We include cells in our re- 
vised concept of structured values in ML-3; as a result of 
this, the need for a paparate class of mointer values van- 


ishes. 


A structured value in ML-1 and in ML~2 was a collection 
of components, each consisting of a value and an associated 
badleatexy: In ML-3, we define a component of a structure 
be now be a (selector)-cell pair, rather than a (selector)- 
value pair. The value of a structured object is still the 


set of its components. 


(program) ::= (assignment) ; ... ; (assignment) 
(assignment) ::= (destination) ¢ (expr) 
(expr). ::= (destination) | (generator) 


| (modification) | nil 
(destination) ::= (identifier) | (selection) 


(selection) -:3:= (selector) of (expr) 

(generator ) sim (integer) | (construction) © 
(construction) ::= [ (field) ; ... ; (field) ] 
(field) ::= (selector) : (cell expr) ; 
(cell expr) § ::= share (destination) | (expr) 


(modification) ::= (construction) (expr) 


SM Sata ob ating ination ging Seem oo veciker 


NE ISTORII OBE SAREE Se RRR 
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Description 
The syntactic classes of ML~3 are identical to those of 
ML-1, with two additions. First, Shere are now two kinds of 


expressions in ML-3: an iehcaes yields a _ value, ene a 


(cell Sxer) yields a cell. The onty occurrence chen 


(cell expr)s is within the (fielaye | oe a (construction) 
(where there used to be (expr)s in ML ~1 and ee e)e The 


vunee for evaluating both kinds of expressions are sotven 
below. The pecen¢ addition is a new kena oF (expr), namely 
the (modi fication) which ‘yields structured objects built | : 


from other structures. All other Syntactic classes are 


exactly as they were in ML-1. 
Semantics of ML~3 (informal) . 


The semantic rules for (program)s, (assignment)s, 
(destination)s, (identifier)s and (selection)s are identical 
to the rules given for ML-l. ‘The remaining elements warrant 


some discussion. 


(1) {expr)s: The ocqurrence of nil or of a 
(destination) as an (expr) is handled just..as in ML-O. and. 
ML-1. (generator)s are either (integer)s, which are handled 


as before, or {construction)s, which are described. in 
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rule (2) below. (modification)s are discussed in rule (6) 


below. 


(2) {construction)s: The semantics of (constructions) 
and (field)s follows directly from the new ML-3 notion of 
structures. A (construction) denotes the value of a struc- 
ture which is generated on the spot. A (construction) con- 
sists of a series of (field)s, each with a (selector) and a 
{cell expr). Each (field) represents a component consisting 
of this (selector) and the cell yielded by the (cell expr) 
(see rule (3) below). Finally, the structured value yielded 
by the (construction) is the set of components given iy its 
(field)s. We make one restriction on (construction)s: the 
{selector)s of its (field)s must be distinct, or else the 


{construction) is invalid and has undefined effect. 


(3) (cell _ expr)s: The two kinds of (cell expr) are 


discussed in rules (4) and (5) below. 


(4) shared (destination)s: A (cell expr) of the form 


share (destination) yields the cell referred to by the 
(destination). This is the basic source of sharing in ML~3; 
shared (destination)s are used to build structures having 
components whose cells are already in use. It is this 


facility which subsumes the ML-2 notion of pointers. 
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(5) <expr)s as (cell expr)s: The cell yielded by an 


{expr) occurring as a (cell expr) is a newly-allocated cell 
distinct from all cells in use and containing the value 
yielded by the (expr). Evaluation of a (cell expr) of form 


(expr) is the only way to allocate new cells in ML-3. 


(6) {modification)s: A (modification) consists of a 
(construction) and an (expr). The value of the (expr) 
(which we call the modificand) must be a structure or the 
indicator nil, or else the effect of the (modification) is 
undefined. The value yielded by the (modification) will be 
a newly-generated structure whose components are obtained as 
follows: 

(i) Each component of the modificand whose 
(selector) belongs to no (field) of the 


{construction) will be a component of the 
new structure. 


(ii) For each (field) of the (construction) there 
will be in the new structure a component with 
the same (selector) and as its cell the cell 
yielded by the (cell expr) of the (field). 

Alternatively, we can view each (field) of the (construction) 
as either replacing or appending a component to the modifi- 
cand depending on whether or not its (selector) belongs to 


some component of the modificand. Note that evaluation of a 


(modification) may cause allocation of new cells, but it 


egal no RSE ei ERR hE Ae Coe ops, Sighs Sat ioe SOR ESR Rn ae pte ES 
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ws vd bebLloiy than ari 22 a Cg qxe Lfoo) eS 203 py oik 
does not in any way affect the contents of eel eing cells. 


flan buoteuelfa-yiwend 6 2: (uqse Lfieo} 6 es paiyiryo50 (IgE: 
Strictly speaking, (modi Hloatisnte are Russi uasemee in ML-3. 
otf ita x SOMES ae) 


isy afd poinisinoo bas sen mt ae 


PYLE LS 


If, for example, the (identifier): x nae a gtcactuces value 
mypoOs tO Cues Lieao> So mobgsuis. TK ra) Sar ya bee fa ty 


with two components whose Vetesoas are a and. Be then the 
“Mio ot alfon wan sdsvolis ou yaw vino eft ef oYyhe 


jesaieicecion’ {b: 3; c:share y] x will Lage the same value 


as the Cohwtticttony’> Parstibrd’ a ‘ct Se 


'soxveas aft Ro saulev oNT ./7gxeo* ce Dis Choir oeoeihes 
BL Representation 
3 ar ee re ae 4 
oft yo eatutouyte 6 ed gdeum (breoft bom aft {len gw nDinw 


We re resent a structured val ° 
are cen = Tee oon adj Jo goatlis sf : Rhys Ieee 


ices ares lead into the nodes. tab: toe. gomreaa cells, and. 


al ifew ‘noitpottiboms sad ya 


are labeled with the corresponding SSPE BED Bs cTPLELAB, . 


se banisido sts @inenogqnoa seonw 


aaa ? simple and habe 2 ese Ef ort 


ia acest alist tranpiationscae-sies? a ( Stecormant)s 


. to (blest: oa ue wot ac 
into Ble So daeneg@moo 2 wo bo ea LD 


41), ASEOMELARE) omets Soar ie pia mes eae: 


LO 


and, (2) kdden Rie Yee setae) singe att 
~2b2eLby odd. TO (uqKe 4462, gd babLory 
are both handled as in MLO and ad, 
Cette dees 2 septic end te, fe Pae tp reas we.’ 7 OTe aw tavidenmaced LA 
@ (identifier) ¢ _Aigentition) edie aad hea ats aig Rte ai 
Ong: WS Re Mossatere sot doe aah sehslat aigicoeneas 


the BL procedure assign} is defined in figure Paice MBH 


gp °° tordesuteve dadt etar 


code is Apts same as for the, , procedure. assign} for, empty; and 


‘ a wmids Ss Wart can) 
integer values of the source (identifier) x, except for the 


Ss ay Sa cai ae i BRIG i a 
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the presence of the same? x, yroue test which makes sure 


gee 


the (assignment) is nontrivial (otherwise ‘ene clear 4s in- 
struction would destroy the value we want to > Keep) . ae x 
has a etcieeurea value, then y will get the same Se her 
value. rhie means, by the tee detinition nt sccuctured 


value, that the components of y will now share with the com- 


ponents of x (figure 3.5=2). In executing any (assignment), 


assign3: .getp (u,v) 
game?) u,v,out 
clear v 


nonempty? u,out 
elem? u,struc 


3.5-2. ° Effect o 
the ML~3 (assignment 
y «+ x when x has a 
structured value 


const *u,v 


return 
getc u,i,out 


link v,*i,u.¥*i 
goto : struc 
return 


the contents of exactly 


one cell will be copied. 


Fig. 3.5-1.. “Definition i m2 eu 
of the BL procedure - } Component cells are now 
assign3 ee 


shared, not copied. Note 
that this is a vast gain in efficiency for ML~3 over ML-1 
and ML~2. The "meaning" of the (assignment) y «+ x, then, 


differs between ML-1 and ML~3. For example, after executing 


vei peal tifhe cit Ect ; vert pe oa ae 
the instructions. Xt a: 234 ‘bs 4 A 'y © xP 2 of s ¥ e 5 
as ie Sag ; reedyodg eof 3 stim d 


exrt 


then the expression a 98 3 x will sees the value - in ML~ ~1 


(ana mu-2), ‘oat ‘will, evaluate to 8 in M3. 


” ‘ tad ot 
Belay as tart 


@ (identifier), + (splection) ne, io 
SFY © ee. is trgnslated into ‘the B code... 


has? x/b, error a 
seall ‘assign3, (x. b, y) 


65) caplection) - (identifier) | 


e. a. a off + a is ‘translated inrte. the BR: cade 


Ps 


has? yracerrgr ; os 


weg : a eee a price 


0801 meaty Dey (eyo 


ae {idepEE RTS). +: ‘(constiruction) 


e.g. y e L ext “a: 2 P of x; e: share z ] is-translated into 


has? x, Ayieror 
-call mie 
sy Skemp) --- 
clear y Lee: Seiden 
.call aseign3: (Ss oie 
call designs; (stamp; 


dink yre-z oe a cee d: b of x; @: : share #1 
BARES SRO eA csadpe 2 an MB}3) cB BO: : 


Note that overlapping (assignment)s pose no problem at all 
wri iekMwiy 2S335.. fess ye ba Howell SESHn Load MM TE Rw as OF ve 


for statements of types (4) and (5). This is due to the 
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fact that component cells of a structure are no longer 
copied on ae However, we do eas othe uae of temp- 
oraries in (assignment)s involving {construction)s, for 
instance, to take Gare of the case when y shares with 

b of x before executing the (assignment) in example (6) 


above. 


Finally, we note that pointers in ML~2 have been sub~_ 
sumed in ML-3. In place of the ML~2 ptr face oe 
we can write the ML-3 (construction) ‘Tval: hace: (destination) ], 
and azaser ML-2 uses val (expr), ML-3 substitutes 


val of (expr). 
ML-3 Movie 


ML-3 _ “i ae 


.setl (x, y,2) 


x * [ ¢:3; d:nil ]; a clear x 


a: nst 3,x.¢ 

clear xd 

has? . XC, @Xror 

“call assign3, bs c, $temp) 
“clear e 

const 4,z.a 

clear 2z.b 


-call assign3, (Stemp,z.b.q) 
clear z.b.r 
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ML-3 BL 

y «+ [ p:share x ]; clear y 
link beer ewe 

pofyey; has? y,p,error 
-call assign3, (y,y-p) 

y « b of 2; has? z,b,error 
.call assign3, (z.b,y) 

x & [ b:5 J] 2: .call assign3, (z,x) 
const 5,x.b 

ze [{ c:share q of y J] 2; has? y,q,error 
link 2,C,Y-q 

y « [ a:b o£ 2; c:share z ] x; has? z,b,error 
-call assign3, (z.b,$temp) 
-call assign3, (x,y) 
call assign3, ($temp,y.a) 
link Y,C,Z 
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y + [arb of 2; 
c:share z)x 


q of y]2 


3.6. Discussion and Examples 


In this chapter we have built up a-hierarchy of mini- 
languages, culminating in ML-3.. We°now relate this develop- 
ment to the main issues that were: raised in Chapter 1. A’ 
major concern with respect to a given "real-world" program- 
ming language is the effect of its assignment operation on 


an environment containing structured data ‘objects. We know 


2 Bi ure ee FEN Se ee Ba een Rent oie org ast co aS en pe panera ene gap 
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that price a an pee nen statement of. the ‘form: X t= e 
will result in the identifier x: *hawing the value associated 
with’ the expression a. What is uncertain - the effect “ot 
such an assignment upon ‘the ‘sharing. ‘relationships among the 
various éefas (in the enviroringst.' Variations ii staring. 

properties can in general induce differences in the effect- 


See eens 

| es give an oxene or adapted fron [Bur se]. _ The only 
date structhtes in the ev Lrommanh: ei be Eipesyine Lists 
with two companents selected oe the respective. ‘selectors 
‘head and tail. Burstall compares analogous programs in “two 
i eeuesaee ‘List-Algol, whiten” combines ALGOL 60 assignment 
with structures essentially eqs valent to LISP lists, and — 
ISWIM ("Lf you See What I Mean"), wah ae based on _the same 
functional lambda-calculus sotions as LISP. | “In both lan- 
guages, the two-argument functioncons returns a list whose 
-head ia the. first argument and whose tall: és the seeond: argu- 
ment; the..funetions head and tail ‘selhect:the.components from 
a list. Berstell's two-programs ave shown in figure 366-1. 
Program “A ; we are. told, oprints.3 while program B*prints 1 
“since it does not cater for the side<effect on y of the 


assignment to x." This explanation gives little insight 
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into why there should be such a difference in the first 


place. The obvious distinction hetween the two.programs._ 


| Program. A: List-Algol _ Program B: ISWIM — 


begin list x,y; . print let x=undef and y=undef; 
X25 CONS (1, nil); let x = cons (¥snil); 
y <= CONS (2, x) 3 oe det y= cons (26x) ; 
; ‘HEAD (x) _ 25 3; : ee Jet x = cons (3, tadh(x)) : 
print (HEAD(TAIL(Y)))| .. xegylt head(tail(y)) — 


end 


“Fig. 3.6-1. Two sample programs with different effects. 


lies in line 4. ISWIM, being’a- functional sgiicative lane 
guage, has no direct counterpart to the epee component 
update statement HEAD (x) := 3... ‘ut. ‘this i. nob the root of 
the semantic die serence between t the two programs. purstall 


neglects to say that even if we change. Vine 4 in ) Program A 


to x := CONS(3, ‘TAIL (x)), Program A will still print 3, 


The source of the trouble ties in a subtle difference 
between the cons functions. in the tivo languages. We can 
pinpoint the distinction by ceepatecens, doth. programs: into: 
ML-3. Line 2 in both programs can be _tranglaged into. 

x + [ head:1; tail: nil ], with the resulting environment® as 


in figure 3.6-2. Line 3 in Program A. is equivalent to the 
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ML~3:- statement y+ f{ head:2; tail:share « 9 while line 3: 


in Program B is equivalent to. Ye [ head:2; tail:x ]. The 


|. tespective resulta axe. shown in figures 3.6-3 and 3.6-4. 


“Fig. 3.6-5. 
After line 3,. 
. Program A... 


Fig. 3.6=2. 
State after 
line 2. 


After line 3, 
. Program B.. 


> tam 


rinally, the revised line 4 for Program bedi wee zende _ 

= re CONS (3, at ocaien Ee is eo sae oe ML~3 statement 
| x «+ t head: 233 eels :share tail of x ee while Line 4 of PrO~ 
gram B is | equivalent to xe L head: a tail: tail gE x i: 


The respective réuults are hoon i acces 3:.6— 5 and 3.6<6. 


Pig. 3.66. After 
line 4, Program B. 


Fig. 3.6«5. After new’ 
line 4, Program A. 
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We can see that the ML-3 expression head of tail of y 


yields 3 in figure 3.6-5 and 1 in figure 3.6-6. 


The difference between the two cons functions in Bur- 
stall's two languages should now be easy Se Reps nrereer 
to cons is a constant or nil, both languages specify allo- 
cation of a new cell to contain the argument valde; But if 
an argument is dome identifier, the Lisp-Aigol cows yields 


for the corresponding component the argument's location, — 


while the ISWIM cons yields the argyment's value. This 
property of the ISWIM cons functien is not explicitly. stated 
in Landin's descriptions of .ISWIM.[Lan.64, Lan-65, Lan 66a]. 
In fact, the only place from which this property could be 
readily ascertained was in Burstall'sa statement that. Program 
B prints the value 1. The ML-=3. code into which we. .-xans— 
lated the statements of the two programs. was determined only 
from the stated results of those programs. What. is to be 
concluded from this is not that Landin was sloppy or vague 
in his language design and definition, but rather that the 
language definition methods which are so. widely. used make it 
extremely difficult to extract aqme of the. properties of 
significant practical iuocebhntat 38 other words, a lan- 


guage which features data structutes will be. better under- 
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stood and better specified if it defines these facilities in 
some manner which makes clear the specific sharing relation- 


ships among locations. 


In the remainder of this section we shall use our mini- 
languages to talk about the data structuring facilities and 


mechanisms of several additional programming languages. 
PAL 


The language PAL [Ev 70] supports only one kind of data 
structure: the tuple. A tuple is a structure whose selec- 
tors are consecutive integers starting with 1. As with 
ML-3, the cell in which a component of a tuple is stored is 
' considered wi integral part of the value of the tuple. The 
PAL expression 4,5,6 specifies the construction of a tuple 
whose components have the respective values 4,5, and 6; a 
such, it is equivalent to the ML-3 piouekeuer ions 
[ 1:4; 2:5; 3:6 ]. Selection in PAL is expressed by juxta4 
position; if the tuple value 4,5,6 is assigned to the var~- 
iable x, then the PAL expression x 2 evaluates to 5 (it 
selects the second component). This expression corresponds 
to the ML-3 (selection) 2 of x. The correspondences we 


have established are sufimarized in figure 3.6-7. 


| 
| 
| 
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The Senreree of vate of a Euphe: a gee and vayue ofa 
structure in ML~3 are very Se abl ane we night expert eine 
lar assignments to Deneve similarly. This, is | indeed the 


case, as figure 3.6~8 confirms. 


"Fig: 3. 6-8. Value of ‘ 
}. pctuple in PAL 


Fig. 3.6-7. Consteuctton: 
and sclect ion, i PAL. 


PAL has a semantic rule that components of a tuple 
share with the items in the list expression that constructs 
it; an example of this rule is shown in figure 3.6-9. This 

— 


sharing can be blocked. using the PAL Unbhare operator ("CS"). 


Figure 3. 6-10 gives an. example of this 


xX + ‘[1:5;276)7 
iy ay © [hex7 227] 


x © [lsS; 2:6)7 
y « [l:share x 
4 rey ro Re 


‘Pig! 36-10. | "Ea of 
sharing in PAL. 


Fig. 3.6-9. Sharing in "] °° 
PAL tuple construction. 
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We discuss one more feature of PAL: the aug function. 
If t is an n-tuple (i.e. tuple with selectors 1,2,...,n) and 
e is any expression, then the PAL expression t aug e 
denotes an (n+1)~tuple whose first n components share with 
the components of t, and whose (n+1l)-st component shares 


with e. Examples are shown in figures 3.6.11 and 3.6.12. 


x « [1:3] nil; 
y « [l:share x] nil 
Fig. 3.6-ll. Example of the 
use of the PAL function aug 


x @ [1:[1:7;2:8];:2:9];7 
2e [1:5;2:6]; 
y « [3:share y] x 


ene ET A cee = 1 mT ae rf 


36-12: “ Another example of aug in PAL 


The above features illustrate nearly all of PAL's data 
structuring capabilities, and they are easily expressed in ML~3. 
Even though the data-structure facilities of PAL bear a 


strong resemblance to ML-~3, we have given a demonstration of 


aren Pippen ee aoe, Bove See ets hunny alsa 
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a full-scale, real-world programming language whose data 
structuring mechanisms have been successfully treated within 
our model. We discuss two more languages. 


QUEST. 


The language QUEST [Fenn 73} provides data’ structures 


called lists that appear very much like PAL's tuples (see 

figure 316413) However, the definition of assignment in 

QUEST treats lists as 
-@pecial cages. for. which 
special rules apply. 


This reduces, . essen-~ 


——— tially, to a.treatment 
Fig. 3.6-13. "Lists in QUEST. 


of lists in the way. 


ML-1 treats structures. Component, values are copied on. 
assignment rather than shared. Figure 3.6-14 presents an 


example. Note that componentwise copying is coded in ML-3 


e [1:6;2:7]; 
ee yo @: flindl;2:nil); 
lof y.« 1 of x; 


2 :aftye.2-0f x7 


Y * X;. 
ze[1:572:x] 


ying of components in QUEST assignment 
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by repeated. component updates, feflecting 4 lack of effi- 
| ciency. QUEST assignments, unlike their counterparts in PAL, 
cannot be directly ivane tated into ME-3 without owing cans 
time values (i.e. exactly what components a structured:-value 
possesses at any given time, 80. they:.can be individually up~ 


dated). 


‘hike ML~2,: QUEST han@les shariny entirely: by means of 
pointers (called references) . 
Their use-de illustrated in 
figure 3.6-15. There is no 
appreedabie: differerce be- 


tween: the: behavior of these 


arcu 6~15,. “References 
in QUEST. 


pointers and those in ML-2. 
Translation.into ML<-3 would © Sy i cee : \ 


be trivially easy. 


For the interested reader, the paper on QUEST [Fenn 73) 
specifies a ree express general Mi~3-iike structures in - 
QUEST using liste aiid ‘references. QuEst functions cons, ear 
and edr are defined, and it is claimed ‘that they. eeniete 
their LISP counterparts. The simulation requires an extra 
level of indizection ehEougnoute a major Enef ficiency (fig. 


3.6-16). Thus we see that using our mini =ienqusces, we have 
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not only able to aL iustrate: the data hnkoncmiee pont sce 


ost Sued 


of QUEST, but we Wave Nie. pereciged a phorteomind in the 
design of QUEST: like ML-2, QUEST fails to retognize the 


fundamental significance of the concept of sharing. 


x + cons (4,nil); 

y & cons(5,x) ° 

templ + “nibs 

_temp2"¢ [1:472: spe temp); 


xX © ptr temp2; 
cane + pi 5; 2: :ptr z vai x]; 


xe¢[val: [lr 2432: [vals pall) a 
“ye [val: ti:5;— “6 


SNOBOL4 


In the language SNOBOL4 [Gris 71], one, finds data 


structures called "programmer—defined data types." . An in- 


vocation of the function DATA causes selector and construc- 


tor functions to re See: . For example, fhe invecation 


DREN COMPLE (Re I)') defines the constructor function, 
vite nas, ; 


COMPLEX and the associated selector functions: Ga and be 


saceine up the correspondence depicted in | figure 2) ee 1?. 
Beyond this seoeeu. in which these SNOBOL, structures behave 
exactly as do all the ateuctures we have | seen in other 


: cae 


Co we ne aa 386 shed S$ nerheg 3 a? ees “ ' 
languages, the ) sharing relationships 1 need to. be, “considered. 
| HOOT one & 38 vi POSE Leb F see sour oF Sued Res ie ere ; 


as Samet “SYK nt 
Laer wet APY athe Pe 
E rao he, i ba oe Bay ; 


But semantic rules eres 


Aa eh, Ladatet acimination ot-the exam- 
.¢, SRE ee jtoistsl Whee TRIS ~al~ ae 


ples ‘is recuires” to prodtiée a Consisten ea ‘unambiguous 


ML=3 representation for the data structuring Fenti tree of 


SNOBOL4. Some detective work is needed here as well: “cack 


ris £ 


of the two” exw ‘Teris ha nia FSF ‘poovtee es ‘Wnsufficient 


‘Snedrmative te wake dudh ‘a determination, but ‘using both 


“together,” shotigh ‘Glues ‘can be “Gathered ‘to. resolve ‘Sosaibie: 


ot Pps rood ae 


sere ee > GS ence in ‘gigure 3 3.6-18.. 


z 


wire sugdedton edt seatien (7 ££ A) KTaM AY AS) 
. The ‘beehe lation into ML-3 may be straight forward, but a 
fom 8 enorgonut toteeles badsiogees edt bas FAGIM.. 


number of other possible translations which would result in 
f-ayepst at bedotgeb saashbmoages ris sytioqu of: 
aifterent sharing properties were ruled out only after 
. 2 ftagugs JOUOKe seeds dotriw ar yume MICE Bids brtsyest ~ 
painstaking examination of the examples in both books. 
sfia me meee evar ew aerutourse afd [le ob es yitoars | 


a 


Surely a discussion of sharing in these books could have 


ct oe Raed 


SRSA «2 chaos Mee ES 
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shed much-needed arene on the pemen tree. poe Sate ecbue ores 


in SNOBOLA. 


“DATA (*NODE (VALUE, LINK)") 
P = NODE(5,) 

Q = NODE(6,) 

LINK (Q) 


ee SE ie Oe Ye Es to 
p + T vatue:5; 
@ & [ value:6;. link; 


he 


4° Tink ‘ot 'G@ ep 


ompieteness .. eteg geen gi 7 eegetegery a. te a 


In this chapter, we “Gefthea a ‘perte fa’ OE ‘pilin -Tanguages 
and used them to mO@el data ‘structuring Facilities th thrée 
representative programming languages. An impontahe” question 
to ask is how complete” ‘our. “podeliag ‘is. ‘In other worda, how 
thoroughly have we Govered the ‘approaches to data structures 
found in these three languages? AY tirat glance. our treat- 
ment cone sbether incomplete: because of:.thei limited: express— 
ive power of the. mini~languages wevdefined.. = But. most-of the 
features not included: i prad wad eeaages' ue inaenendent 
of the notions of data: structurescdn. theisehse: that the. way 
such: features are: defined in‘an. actead programming language 
has no bearing on how the. language’ approaches corneepts of: 


teh Leet ae SO ECP pee nie 
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meee slcsivaves: The pact that our mini~languages lack 
character strings and conditional. expressions, for instance, 
does not reflect on their completeness for ‘describing data 
structures. - 

In’ PAL, there are only’ two notions we have not. covered 
which have: a: direct bearing on data structures. ewes weiss 
itrary integer-valued: expressions ca’ be used. to select com=. 
- ponents from a tuple. For example, the selection xn re- 
fers to the component of the tuple x whose seleetor is. the 
value of the variable n. This, cannot be. translated into our 


mini~languages, which allow only: const nt 


(selector)s (the 
_ML~-3 (selection) nofx would. look for a component. with 
selector "n"), The second uncovered feature in PAL is the 
built-in function Order, which when applied to a tuple 


yields the number of components in the. tuple. 


Neither of these two notions canbe expressed in our 
mini-lanquages, but it was not our goal. to: be able to do 
so. For these two data structuring feetures, the semantic, 
issues are well understood; we don't really need: to treat 
them in our mini-languages. Extendinyy: thé: mindxlenguages to 
handle extra notions like these would.only serve. to ruin the 


syntactic and semantic simplicity of the mini-language 
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approach. 


In QUEST, the only data-structuring features we did not 
treat are the use of eeereus ise to select components from a 
list, and several built-in functions ‘that operate on lists. 
As with PAL, we feel that the issues raised. here are outside 


the area of our main concern. 


With SNOBOL4, we completely neglected the area of 
arrays. -Although arrays are highly relevant.to the issues 
we are interested in, they present some difficult problems 
for whose solutions additional mechanisms are needed. : We 
discuss some of éiiees probiems' in Chapter. 5. 

The three languages covered in this section are all 
"typeless" languages in the sense that there are no dec- 
larations associating identifiers with particular data 
types. In the next chapter, we deal with “typed” languages 


and some new semantic issues they introduce. 
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Chapter 4 


DATA TYPES AND TYPECHECKING 


a ae oe Whi We Want .2 ree System ane cae 


In this chapter we will add a Hew ‘Faedt’ to the “design 
of our previous mini-languages. Considér the MU-3 “ 
(assignment) y + xy which directa that tha).cortents of the 
eell for x sccpuasen’ inne: sia euanede uch Wrenaiaeea, 
this (assignment) into an invecation of the BI: procedure: 
assign? (defined back in fig. 3.5-1).. Bvery time thie pro- 
cedure is called, there is: a separate: set: df: teats per- — 
formed to check whether the cell for the first parameter. 


(which .corresponds to x) contains én. integer or a structure. 


The set of BL instructions chosen to perform the assignment — 


operation depends on the result of these tests. In prac 
tice, however, a programmer will usually know in advance 
whether the identifier x will take on ihteqer ox structured 
values. This knowledge makes these runtime type tests in 


assign3 superfluous. We would like some way of telling the 


translator not to make such tests where they are not needed. 


The technique of static typechecking achieves these 


goals, its basic idea is to partition the set of values 
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into convenient subsets called types. The translator can be 
informed of the programmer ' 8 intentions of = keeping values 
only of a certain type in some gen eat, | with this xnows 
ledge, redundant runtime type teats. can be eliminated. gut 
it is still necessary to prevent type errors. For r example, 
suppose we tell the translator that the variable x will take 
on only structured values.’ Each time we access the value of 
x, the BL code produced by the transiator will fetch the 
components of x. If we somehow place an “integer value 4 in 
the cell pound to x, then aes? execution the interpreter 
would attempt to extract ‘components where ‘there ‘are none, 
yielding undefined, probably erroneous 18 results. 1 To prevent 
such type errors from occurring, we oui like = to nave: ‘She 
translator test each (assignment) to make sure it couldn't 
specify the placing of a value “of one ‘tips sate a eerie in- 
tended to hold values of another type. Any {program) con- 
taining (assignment)s which fail this. test ia invalid; the 
translator will notify the user of such an..error in the. same 


way that it flags syntactically erroneous (program)s. 


In testing (assignment)s for validity, it will be use- 
ful for the translator to know for each (destination) the 


type of values intended to be stored in the: associated cell. 


a 
ae 
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‘This criterion can help - aéeide “how to partition the. ML~-3 
values into types. If we divide wales into just two types, 
‘integers cae wetcetiren: then the ide criterion is not al-~ 
ways satisfied. Suppose the (identifier) x is specified as 
Sautawr outs i eegeeured saldee: Then the values yielded by 
‘poth of the (expression)s i" as £31 b:4 ] and 
t at 33 bit ce5s ad:6 ) J can be stored -in the cell bound to 
x, but wa cannot say seethane about Gis ee of the 
(destination) b OE x. In rn one case it has an integer value; 
in the. oehes case, a structure. Thus "finer type 
classifications: are called ‘for: we will want to ascertain 
from the’ type ofa structured value what coeeoues it has 
and the type of each component. Such a type eyeter is the 


basis for our next mini-language. 


age 4 -= Stati 


Mini~Language 4 (ML-4) adds the notions of data types. 
and static typsvhecking to the contepts we aeveloped in the 
previous’ chapter. Specifically, 1! Ye an’ extension to ML-3, 
associating to every (expression). and.to every cell a par-— 
ticular data type. For our purposes, we consider data types 
as sets of values. The set of integers is:an ML~4. data 


type. Further, the set of all structured values with a 
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given set of component (selector)s such that the type of the 
component associated to each specific (s@iector) is-given 
also is an ML-4 type. With this collection-ef data types, . 
if we associate a type to each (identifier) mentioned in a. 
{program), then we shall be able to determine ‘the type asso- 
ciated with each cell referred to in the (program) . More- 
over, for any particular data type, one can determine whether 


the value yielded by a given (expression) belongs to this type. 


Syntax of ML-4 


The rules here govern the syntax of that pane of ML-4 
which is not found in ML-3 (namely the type system) . We in- 
troduce the new primitive syntactic’ class (typename) to de- 
note the set of underlined alphanumeric strings beginning 
with a letter. The distinguished (typename) int has partic- ; 
ular significance, which will be discussed’ bélow. 


{program) ::= (prelude) ; (assignment) ;...; (assignment) 
(prelude) a3= (defn) ;...; (defm): :\ (decl) ;...7 (decl), 
(defn) z= (typename) = (structype) = 

istructype) ::= [ (comp del) 1..33 (camp deel) 1 

{comp decl) ::= (typename) (selector) Cae ane 


{decl) :s= (typename) (identifier) ¢...7. (identifier) 
The remainder of the ML-4 syntax is identical to. the syntax 


presented for ML-3, with two exceptions. First, ML-4 has no 


Beste SO a WED AL te ase Ba OE Bg tes ae 


aa 7110s Deg tre sgce ts 


(modification}s (which we sinply won't have cecasion to make 
use of), and second ;  (eonstiuction}# app@ar slightly differ- 
ent: | 


‘{eonstructiony r= (typeriame) [ (fidldy ¢...7¢ (feild) | 
(field) end MCCLL ORPED ges. ffan 


(The (selector)s that no longer expliqitly appear in the 
_ (field)s of a (construction). may, he found, in the (defn) for 


the (typename) of the (construction) .) 


Description | 


| ve. ns to anternret the new syntagtic classes. A. 
(program) in Mi~4 is essentially a (prpgram) in. ML-3. pre- 
ceded by a (prelude). The (prelude) is a sequence of type 
definitions ((defn)s). followed by a sequence of declarations 


((decl)s). A (decl),. consisting. af a, <1 e), and a list. 


see ee 


of (identifier)s, specifies. that those, (identifier)s are to 
assume’ values only. of the type given: by’ the (typename). 
‘Types in ME~4 are denoted by menbers of "90 syntactic 


classes as  $olldws: 


(1) A-{typename) is either the syabol int (which de~ 
notes the type consisting of integer v: verses). or the 
- nathe associated with: some typé' py a TaeRn |: 


(2) A (structype) _ denotes a structyred | type. Ai. 2. a 
type consisting of structured values). The 
(selector)s and types of the associated components 
of a value of such a type are specified by the 
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{comp decl)s (component declarations) ina 
(aructype) >: 


Observe that if iene the type of a , structured valve, then 
iam fe Suteastenciae 

we know the type of each of its components. mere are two 

basic purposes for using (egsei ane) we firet, - cvovide for 

multilevel structures (i.e. struétures with components which 

are structures), and sécond, to alléw for recursion~in type 


definitions. We discuss recurs4ve types later. ~ 
- Semantics of ML-4 (informal 


4, bedi Satine the _ 


wae ee 


nate) od (eteuctyee , 


ML~4. Elements 3 hese) ctued tigen 


define data types according to three. gules:. 


(i) The (typename) int denotes, the, clase of all 
integer values. 


(ii) Suppose Byreee 8 are (selector )s: and — 
tyreeee are syntactic items denoting data 
types. hen the (structype}- [t, Ss; Y yien 

. denqtes the class of all atructuted with 
exactly k components with: ({selectwr}s. 
S,,....8, Such that for each i = 1,...,k the 
value (ik ‘any) contained 4n- the® component: cét1 
selected by 8; ‘belongs to the type t. is 


(iii) If tis the. (typename) Of a ‘@aetn), “hen t 
denotes:. ‘the type specified ‘by the. (structype) | 
of that (defn). In thi8 cage 'we say that the 
{defn) defines the (typename), te. 20 


These rules give the semantics for type definitions in ML-4. 
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Note that according to rule (ii), if x is a value belonging 
to a structured type t, then the types of all the compon- 


ent cells of x are determined. 


As examples, the objects of figure 4 2=1 belong to the 
type int. In the presence of the (defn)s 


pt = [ int p ] and t = [ int a; pt b ], 


Fig. 4.2-1. 
Objects of 
type int 


the objects depicted in figure 4,2-2 


belong to the type t (which is the class 


of all two-component structures with 

a-component of type int and with b-component a one-component 
structure whose p-component is of type int). Note partic- 
ularly that a cell constrained by our type mechanism to hold 
values of a given type can be empty. A value may belong to 
more than one type (par- 
ticularly if it is a 
structure some of whose 
component cells are emp- 


ty). But given any value 


v and any type t, one can 
always tell whether or 


not v belongs to t. 


A (typename) does not have to be defined textually be- 


~L13= 


fore it is used in a (prelude). For ane aeee. the Sng 
sequence tl = [t2 c]; t2 = [int d; int el is perfectly 


—_ 


legal. A rionteivial application. is the definition of recur- 
sive data types, which arise in ML-4 when a (i oennney 46 
used as part of the ¢structype) in its definition. con- 
alae for example, the (defn) r = [int a; rb). This | 
defines a type named r consisting of two-component struc- 
tures for which the a-component cell can hold only integer 
values and the b-component cell can ‘hold values only: of 

type r. Although it sounds circular, it is perfectly well 
defined, Values of a recursively defined type can have sub- 
structures nested to an arbitrary depth; and BL<objects 


representing such values frequently contain directed cycles. 


We make three restrictions en (defn)s in se First, 
the (selector)s occurring ina (structype) must be distinct. 
Senonds a (typename) can be defined only once in a (program). 
Third, the (typename) int must not be pete tae Any 
(program) not obeying these restcicuiace: tar eypntectledlly 
invalid (i.e. is to be rejected by the translator) . -- The 


meaning of an invalid (program) is undefined. — 


(2) Declarations: As with (defn)s, the semantics for a 


{decl) does not specify any particular actions to be per— 
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formed at runtime. a éftect of a a (decl) is to cause the 
(identisier)s in it to be astociated witty ~ ‘type named din 


the (deol). ow 


tectically valid, eyery 


in oydex for.a (program). to be # 


(identifier) ocgurring in some (Asai must, appear. exact- 


ily once ijn the (program)'s, (declys. :: 


ing in some (decl) must be defingd exactly once in the (defn)s. 


. Prom the above. senmitic rolew SOE Taste and (decijs, it 
B- posbiihie: tp uniquely determine eae eyper OF any {expression ) 
a #. eyntactdval ly: walis progevag: thke is aone as follows: 


44) Sagpome: the foxpreesion)> is: ao (auatinationy. If it 
is an (identifier), then this (identi fiery occurs in 
sin | eebtiy: Gneitdeel} ant ite: eppe iso gi vet By the 
(typename) of the (decly. If it is a jastacticns: 
then it consiste of a (selegter) and .ag. (expression). 
The type of the 6 anirondnat hl which can be determined 
saeara reget me _byugtused type .designated 
by a (wtrietype) . whe ty type of the Pic pihepens then, 
is given by the. Ct 48, the,.Ccomp decl) of the 
(attudtypey that” contains the given ¢: selector). 


(4) TE the: (eepredsion) te a. pvsoagrt ‘there ‘are two. 
cases: ( a are Sed pdt. rege (construction)s 


Thus we ca detemtiine from tue euseadle ot #yntactically 


~~ 


valid (progtam) the type of aay Cenpréuciony; ‘this type ad ! 


: given aad Precisely one. (typename)... FOE. OxA ss 
presence of the (prelude) tyme = lint, a1 xivme Bh 
ytype = (ht ey int 4]; xtype x: yeype y the type corres- 


SER Ae a re ee eT PS OR ee eee 
at ee 
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pondences shown in figure 4.2-3 are valid. 


(3) Assignments: the seman 
tics of an ML<4 (aesignnent) spe- | 
cifies the same Puntine actions See. 
its ML=3 eountorback: in addition, 
the translator is i cgbcca se per- 


form certain additional tests. An 


(assignment), as ‘eitove: consists 


‘|pig. 4-2-3. Types of 


ofa (destination) and an ; 
| gample (expressign). 


{expression). The ML-4 type hae 
tem forces the cell referred es by, the (destination) to hold 


values only ofa certain | type. “Thus the translator must ver- 


ify that the value of this (expression) matches ‘this type. 


OA (construction) in which the components 1s fail to match 
the types of the sorresponding fields in the (defn) of its 
(typename) is an invalid (expression) and has undefined type. 
For example, if we define z= (int a; int b], then the 
(construction) Z[172;3] is invalid because of its extra 
component; the (construction) ‘gU1r 2[273]] is also invalid 
because its b-component is of type z rather than int as re- 


quired. We also call a (construction) invalid if its 


(typename) is not defined in the (prelude). 


RIRPRBETSRR A RIP ES PRESSES sete RE AR net Me pe i MNRAS AES SERA RE 0 ABR OE ES Eo ne RA OS EN re TREN TEESE AIS BE ERA SE BEE 
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An Mies. Cerpge em) is eo if in any OF its 


Pal? Ol i : + Reenter. 


(assignment)s the ‘type of the eens ie un- 


definea or fails to match the type of the (destination). 
: . PEP SES “AR oe 


| Zach of these. wo types te ‘siven by precisely < one 
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(typenames ¢- these types 2 are define to match if and 


only if chety (typenameys are identical. the ‘mechan~ 
isms we shall, dering for the cus insure that . can 
PER. ~erotead ws 
“aways dstermine ‘whather or: not a given Mn (program) 3 is 


valid: Ahece darn ) need for runtime type cane. nor are 
ay Reet Soft 


oes any ingerne aye errors. However, a runtime error 


2 wo Boa aad. 9 


‘ ae 


3 


will occur if there ae an attempt to D extract. components £ from 
an empty cell of a structured type. For cage ia ML~4 


Bo 


(progean) sl = iipe ar 82 b}; 82 = [ant ol? sl x; 

xe > e113: mill: ¢ “of ‘bo of. xe 4 a will ‘fail on 1 interpretation 
of its last lanai gunéat) eines: “the: interpreter will “look. 
“for 2 a nonexistent ‘c-component in the ‘empty “celi for. b> o£ x) 
even. though ‘the: ‘type ‘of te " (dentLantiony’ ‘e “Ge ‘5 ‘of x “ (int) 
matches the type of the’ (expression) 4. ° thus we require 
“runtime tests to cHeck the (selection)s in Mi-4. Generally 
spesking, tasting tor empty ceilé is usually mech easier 


than testing the type of the contents of a ceil at runtime. 
Sole aid ek dart kgob gor: a. ; 


If we strip off the (prelude) from a valid ML-4 


ESR acne a a tia cont ROR MR A 
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(program), then we will have in essence an ML-3 (program) in 
“which each cell takes on values of only one type. Moreover, 
the effect of executing this ML-4 (program) is identical to 
the effect of executing its ML-3 equivalent. 

Translation into BL 


To give a precise formulation for the semantics of 


ML-4, we describe the translation of ML~4 (program)s into BL. 


With the previous mini-languages, it sufficed to show the BL 


code corresponding to various program constructs, namely the 


different kinds of assignment statements. .This is no longer 


sufficient in the case of ML-4, since the semantics now con- 
tains rules for typechecking by the translator. We must 
therefore also describe the typechecking procedures per- 


formed by. the ML-4 translator. 


In discussing how the translator performs typechécking 
of ML-4 (program)s to determine their validity, we begin by 
describing the information supplied to thé trasielator by the 
(prelude) of a (program). We shall treat the ‘translator as 
a BL procedure. As it processes. the (prelude), the trans— 
lator builds two component objects in its local: structure: 
one component named gdefns which represents the type defin- 


itions, and one named $decls which corresponds to the 


Taghdnedichiens: rte, aire eee Es ett ets Wa eS Yer gees so Y oe ack cet cane dae ager 
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egos. 


_ the declarations. $defns is a structure which has one com~ 
eapeas fer ene typeenee) ee ee ese 
component of $defns isa structure with information on the 
type associated with the (typename) . For each ccypensme? 


defined in a (defn), the corresponding « ‘Goeonene of Sdefns 


has’an “ni” field with the rabér of® #é*in ‘a value 


a of that type, numbered tietde giving the (selector}s of the 
compénenté in the propér ordey, ‘atid a “val" field giving the 
 tybés of the components (Ey means of links to the proper 


sie 
a 


ent 6f $defns has only a 

at ~congemene “dodldiniig the élemantidy vaiue 'ise+> ‘gaecis 
is a structure with. one dosponeit “fo¥ @adh (identifier) de- 
clared in the (prelude. ‘rf, day, “tnd ¢idekti rier)” x ty. 


kné Of ‘Sdacls 


declared to have type t, then dis’ eras as Oe 
» Shares. with the +- 


<< ay of $defne, In each.ef figures 
ASQ ey 442-5 and ‘4.2~G we give *@ :Gpretude).-and -ethibit the 


| Objects: d6Ens aad Sdecle constructed: by the translator. from 
. the (prelude)... Bhe type sekely ( typename) 2 in :figane 4.25 
is recumsively defined; obseuwe that Sdeins ahas:.e directed 


eycle. in tiie. dase. i us Pen Oe ia WL 


Gee these objects have been constriéted by the trans- 


lator, all tHe information required fox “typéechecking is 


Sap hte Es Baran a te RET SAE S Te Fisk TRNAS RE EES OE ne 


SEAT Aga RAM Sue aE oat Saban SPE gee ee 
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| available. Each type to be associated with some cell re- 
ferred to in the (program) is represented by a component 


node of $defns. Two types match iff they have the same 


Fig. 4.2-4, Fig, 452-5. $defns and $decis |. 
(prelude) structures for the (prelude) 


= [gk ps dnt vli 2 x.y, dgt m 


Fig. 4.2-6. S$defns and S$decis. for 
the (prelude). tl =. Be a: bj; 
£2 =. [int c}; sx, oie . 


(typename) . To Pe ee ee performs the 
actual typechecking, all that needs to be shown is how to 


access the node for the type of any ML-4 (expression); once 
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we can do this, the typechecking is straight forward: an 
(assignment) has a type error iff the nodes for the types 
of its (destination) and its texpréasien) are dieriact.- 
The type of an (identifier) x is given by $decla.x. 
The translator will mark a (program) invalid if any of its 
(identi fier)s ana. undeclared. Ig B is the node -for the type 
of a (destination) D, ‘then the’ as of the (selection) 
s of Dis given ‘by the sean pve a: the translator wae 
ties ae part of ite typechecking that values of the type of 
D. do indeed have a-coaponents. hus waiiGud: aneaeecin the 
node for the type of any (destination) in an ML-4 ipregrany: 
Figure 4.2-7 illustrates some sample ML-4 (aseignment)s in- 


volving only (destination)s and gives BL typechecking code 


ML-4 code } “Bi: typethecking cae 
aire 2 $decis. > $decls. XO 


fess $decis.x.val,a,no 
43 pb Stocks .#. ddecls-¥.val- BRO 


“gdecia.y.vaz/b to” 


t $decis.y.val-h, Sdecla.2.n0 


Ths? $decls.y.val,b,no 
2? $decls.x. val,a,no 
P Saeclis\x.val.a.vat,c,no 
ne? $decls.y.val. b, $decla.x. val. a.val.c,no 


Fig. 4.2=7. Examples of BL i typedhecking. -_ 
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to determine their validity. A pranen se the label “ne7 


oe ABs ays ot 


inaioates that the (assignment) has a ups error. 


If an (expression) is. an (integer), ‘then “tte: type” is 


given by cha: node ‘$detns. ant. The type of a (construction) 


whose (typename) is Pe is “pean by: the node Sdetne. t, pro- 


vided the (construction) is valid. ‘To check this, the types 
of the components’ in ‘the (eoheenaeisan) must match the 
(typensine)s in the (structype) that defines t; moreover, 


there must he the. same number: ‘of ‘ecimponents in both places. 


Thus the translator can. access | by OEE scheme thie jhode for 
the type of any (generator). “Asa Seault, we now see how 
the translator: aceasaee the nodes: fox: the types of arbitrary 
ML~4 . (expression)s. “Figure 4.2=8° gives some. erie of. 


ML~4 (assignment)s containing arbitrary kinds OE 


(expression)s; along with each (asim .t) we show BL code 


which tests its validity. This completes our picture of — 


how the translator performs static typechecking: the mech- 


anisms should be clear ‘trom the exumples in figures 4.2-7 


and 4.2-8. 


The actual BL code generated by the translator (i.e. 


the BL code to be interpreted at runtime during the execu-. 
Pers SP sae soit aN Sse lia getup. Sey as aun es 
tion of an ML-4 (program) ) is similar to what we presented 


ee are Stee eae wep hye 3 eas 
: 
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in the section on ML-3. There are two. differences reflect- 


Ze tf2]} - \same? $decls.z,$defns.t,no 
| games tc L.Stemp ./* wiluee:sné ‘type t 
must have exactly 
Oe Nasa, CR: Reames, / 
eg? ‘saeeee. t. Ln, $temp, no 
Select $defns .&l Stemp-/* name of let 


component 


Mi ame na he ll a 


e? ~ Sdecia .w, $d0fne. Ee RO 


we = re Ws i 
t- 2, ¢ temp 
; a2 _ $defne.x. .n, $temp,1 no. ee 
2 ee ‘Seléct Sdefus.r, 1; f : 7 . é 
Aes Sdetas5 val. *$temp, sdecis. w,no 
: ac PE; Stiditip * | 


S33 en *Stemp, $decls.x,no 
same2 Sdecls.y,$defns. 8,no 


y © s[tlb of wi) 


| bi homers: ol «Stine 
| ‘eg? Sdethe.2.2,$tenp,: no 
| bgelkect gitefneim,d artemp -. 
me? veers 2 ee: *stemp, Sdefne. t,no 
‘{gonst 1$temp. 
eq? $defns.t. n, $temp, no 
has 2. ‘$decksai.val byn0 * 
select $defns.t,1,$temp 
> | ape? Ste fect sel -* Seemp, - 


na as $decis.w. val.b,no 
Pig. 4,.2-8. More examples of BL typechecking - 


ing the switch of Eypechecking from runtime to transiate- 
neni Firat. occurrences of (selection)s in ML~3 yield run- 


time vn -tadke., such as the BL code has? x,b,error for 
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the ML~3 (selection) b of x. In ML~4 thie runtime type 
test is replaced by the simpler and faster test | 
nonempty? a aceer, which makes sure there is no erroneous 
arcane to access component cells of an empty'cell. 

The second change is eae ine Ronoiibates peoeaaiee! 
assign3 with all its type tests is not needed at all. The 
BL, code generated from the (assignment) y + x depends on 
the type of the agntination) y: If its ‘type is int, then 
by virtue of the translator's static typechecking we know 
that x can hold only integer. values.. In this: case the: BL. 


. - Gode in: figure 4.2-9 isjgen- 


clear ey 


nonempty? x, skip. 


const *x,y 


erated. If-yois of.a struc- 


tured type, then the trans- 


Vator knows that its 


skip: ... 
Fig. 4.2-9. BL code for 
the ML-4 assignment.) 
y« x when y is int 


CB@LECKOR) Bs Bye see + Sy 


are given .by 


Ss, = *(Sdecls.y.1) , ... , 8, = *€$decls.y.* (Sdecls.y.n)). 
In this case the-BL code in’ figure 4.2-10-is generated. The 
translator can always tell which case applies by testing 
whether the pathnames $decls.y ‘and $@efne Jint lead ‘to the 


same cell. The BL instruction same? $decls.y,$defns.int,go 


performs this test. A branch to the label "go" indicates 
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that y has @® structured value agar that the second ‘case | 


_ applies. “thus, * ‘sub- 


‘stituting the as Src 
’ tat bs oS PTE KYO 7 Po boas 23 
¥ ey Ke *s, test for the cess 


ste felt ot “eed! Che BL todé' of fig- 


AAR Fe ORR Ob dua #29 alia @02-10 
skip: ,.. . ; 
ae 4. 2-10. “BL code. for = the 


wieten? procedire ‘e, we 
Senet? he BI 'ettte® 
# der dew 


yielded bye the: WL~@: tremmleori-. ‘thaws ete 
sex iption: of the: translesian of eatiine date Bb. and: #. places. the 
ae 
_ Semanticacot: MB! on. Sheer and re caer 


Gee 


- Most programning ranquages panenican deta, strugtusee 
have a type syetém wini lar to. that oF Mitr ‘eho ware of 
ving, +6..dene at translation: tie: sather thes: 
ae bie. seetion:.we -¢ est..the Gate jetenetuning 
- faci hithes: of. thee. of theese languages, -uskig Mi-4 aga: 
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treatment of data structures. The structures are ose 
records, and the ALGOL W analog to an Mund structured Fype 
is called a record class. An ALGOL W record class deciar- 
ation can be represented by an na ei (aemn). _zigure 4. 3~ 1 
shows how the two languages define ipeeen’ of structured 
objects; the ML-4 type with (typename) pair corresponds to 
the ALGOL W record class named pair. Structured objects: are 
built in ALGOL Ww through the use of cecord designators, 
which are analogous to Mid (eGnRENaeE ton) 85 expressions in 
| both . languages which build structures from the fe "pair" class 


are also Bhowh in figure 4. 3-1. 


‘lobject construction 


Fig. 4.3-l. A “parallel between ; ALGOL W and ML~4. 


There is a major difference eons ALGOL W and ML-4 
with respect to these elements. Although a record desig- 
nator builds a structured object “in AELGOEL W, it does not 
Sisaaiee its value the object it constructs. In fact, rec- 
ords are not! ever ‘values in ALGOL-W. ‘A-récord class is not 
a legitimate type in ALGOL W; records are accesved through 


values of reference types. For instance, the ALGOL W record 
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designator pair(3,4) in figure 4.3-l yields a value of type 
reference (pair). ML-4 will treat reference expressions in 
ALGOL W similarly to the way ML-3 treats pointers in ML-2. 
The correspondence is depicted in figure 4.3=-2. Note that 


in dealing with 


ALGOL W 
record pair (integer a,b); 
reference(pair) y,2; 

Jy := pair(3,4); 2 :=y 


ALGOL W records, 
we need an extra 


level of indir- 
pair = [ int a; int b ]; 3 

refpair = [ pair ptr ]; ection (the "ptr" 
refpair y,2Z? 

y «+ refpair[ pair[3;4] ]; component). This 
Zey 


Fig. 4.3-2. Reference expressions (at least with 


in ALGOL W. 


respect to our 
scheme of rep- 
resentation) is the same kind of inefficiency we encountered 
with ML-2. It is worse here, though, since ML-2 made use of 


the indirection only when sharing was needed. 


Components of a record can be accessed by selector fun- 


ctions in ALGOL W. Pigure 4.3-3 ; 


ect fae) 
fut _[a of ptr of 2 


Fig. 4.3-3. Selection. 


shows the correspondence between 


selections in ALGOL W and ML=-4 


(z is of type reference(pair) 


in ALGOL W, refpair in ML=-4). 
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Once these ate ference concerning the construction and 
selection a aa have been taken into account, we fing 
that assignment, ehareny. and typechecking in cuacaaodl w are 
almost eer er ee the "obvious" ML-4 counterparts (e. g: 
replace ":=" with isis In this respect, ALGOL WwW is_ similar 


to the language SHOROES described in section 3. es 


PL/1 

PL/1 was one of the earliest languages to have compile- 
time typechecking and to treat both dat@ structures and 
pointers. Most PL/1 constructs handling these notions look 


markedly different from the 


PL/1\| 
DECLARE 1 X, | 
2 I FIXED BIN, 
25, 
3 J FIXED BIN, 
3K FIXED BIN; 
DECLARE Y LIKE X; 
DECLARE Z LIKE X. 


constructs we have seen in 


= [int i; pair s]; 
= [int j; int k]; 
x i Sau 


- Fig. 4.3-4. Structures in PL/l. 


storeay dnaread,- Me phi 
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other Janquages: ‘Figure 4. 34 shows how PL/L handles a 


‘sample structure aan. gives an att equivalent. We make two 


pbaervetionk: Firat, all component cells of the P/1 prenew 


tures in ‘this example are allocated ‘en the declarations 


‘are interpreted. with mind, component cells are pateceted 


Bop tie 


when the eeeacences vaias is actually canslicsintea: Second, 
a PL/1 steucture assignment like Y=XK in fig. 4.3-4 “‘aig- 
r st :copping ‘(xeserdively for 


‘tnltke RIBOL “Ww, thére ‘is ‘no 5 sharing among PL/1 ctnaee 
tures uritit ‘we introduce pointera_and the. attribute BASED. 


a + p 4d a PLA. vakiable ‘declased to be o peisttar, niet de- 


claring a structured variable with the attnttaite BASED (P) 
PIEEEAEeS a vast. conceptual ‘ai Sena, “thie variable no - 
longer: ignition * ‘location, where struttured objects may be 


the role of a structured” _Eyee.. 


Figure 4. 3-5 “sith eset of PL/1 dectarat ions’ Anveiving 
BASED structuted Sand! gives, a prrespapting a Gprelude) 
aid wet: of ato \w-dedjerations. a ai : 


* te ‘2 
é . pony 


Although the m/l Auclarations: ot ‘tigre 4.34 specify 


gibestion of Midrage | 


cation of camponent cells as well) , the sedi sivied of LIST 
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in figure 4.3-5 does no such thing. BASED structure values 
in PL/1 are constructed through the use of an ALLOCATE 


statement. Under the dec- 


PL/1 
DECLARE (P,H,T) POINTER; 
DECLARE 1 LIST BASED(P), 

2 BACK POINTER, 
2 FWD POINTER, 
2 NUM FIXED BIN; 


larations in figure 4.3-5, 
the PL/1 statement 
ALLOCATE LIST may be rep- 


ML—-4 
ptrlist = [list ptr]; 
list = [ptrlist back; 

ptrlist fwd; 
int num]; 

ptrlist p,h,t 


ALGOL W 
record list = 
(reference(list) back; 
reference(list) fwd; 


integer num); 
reference(list) p,h,t; 


Fig. 4.3-5. PL/1 BASED 
structures as types. 


resented in ML-4 by the 
(assignment) p ¢ ptrlist[ 


list [nil:nil:nil]]. 


Since LIST is declared to 
be BASED on the pointer P, 


the allocation causes the 


value of P to be set to 


point to the newly-built 
structure. The result of 


memes. Moe eo this allocation is shown in fig. 4.3-6. 
P 


BASED structures in PL/1l are ac- 


cessed through pointers. In our LIST 


example, a use of the name LIST refers to 
Fig. 4.3-6. 
Value of p. 


cently constructed structure BASED on P, unless P has been 


whatever the pointer P is currently 


pointing to (which will be the most re- 
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subsequently updated). To refer to a. previous allocation, 
one must use a quasified reference such as T -> LIST (which 
indicates whatever the pointer T is currently pointing to). 
Figure 4,.3«7 draws the connection between PL/1, ALGOL W and 
ML~4 in accessing fields of structures (it is assumed that 


the declarations in fig. 4.3-5 are still in force). 


LIST | 
? => LIST 
LIST.NUM 
| 2 > LIsT.wuMm, 

Fig. 4.3-7. Accessing 


ptr of p 


ptr of t 
num of ptr of p 
|) nom pf gtr of t 
fields. 


The meaning of assignment in PL/1 is similar to ALGOL WwW 
xcage for its handling of structured values (which ALGOL W 
does not choose to handle). | In this case, as we have said, 
PL/1 copies rather than induce sharing. — All shering of data 


in PL/1 is done through pointers. 


“‘Typechecking in PL/1 differs from ML-4 and ALGOL W in 
one major area, that of pointers. -‘the.ALGOL W, translator 
insures that a reference value ean poiat to records only 


fxom one record clasa; if.cl and o2 -axe dis t4) 


classes, then any attempt to make a value of type 
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reference(cl) point to a record from class c2 will be caught 


by the translator and marked as illegal. The type system 
for ML~4 imposes essentially the same restrictions. How- 
ever, a variable of type POINTER in PL/1 can be set to point 
to values of any type at any time (including nonstructured 
values). This causes difficulties of the same kind that 
static typechecking is supposed to eliminate. For example, 
in the PL/1 program segment of figure 4.3-8, the assignment 


P=Q is legal, even though P points to a structure of type 


DECLARE (P,Q) POINTER; mi—4| 


DECLARE 1 Ml BASED(P), = [int j; int k]; 
2 J FIXED BIN, ptrml = [ml ptr]; 
2 K FIXED BIN; ptrm2 = [int ptr]; 


DECLARE M2 FIXED BIN BASED (Q); 
ALLOCATE M1; 
ALLOCATE M2; 

= Q3 
M1.K = 5; 


ptrml p; ptrm2 q; 

p « ptrml [mi [nil;nil]]; 
q + ptrm2 [nil]; 

pe q 

k of ptr of pe 5 


Fig. 4.3-8. Lack of type restrictions on PL/1 pointers. 


MA tlk A Mt one ee ro 


Ml and Q points to the integer M2. The reference to Ml in 
the following line (M1.K = 5) designates whatever P will be 
pointing to (which is the integer M2 since P has just been 
assigned the value of Q). Thus there will be (depending on 
the implementation) a runtime error or at least an erroneous 


result as an outcome of the attempt to update a component of 


-132- 


the integer value M2. “The ML-4 teanaletion of this program, 
also shown in figure 4.3-8, is invalid. sine in the. 
(assignment) - «+ q the tynek fail to mateh (ptrml as 
ptrm2) . If in thé PL/1 program we had declared ee oe 
BASED on P, then the eeeuihine Wak (ordgean) would have 
two conflicting declarations for P, iadlch woule wes render 
it invalid. Thus we see that the Edeesuacking avec: iH 
PL/1 fails to catch a iste eiaas of. programs which might 


have runtime type errors. 
ALGOL 68 


The treatment of data structures and pointers in 
ALGOL 68 is linked to-an intricats system of types and type- 
iieding). ALGOL 68 is a difficult language to learn and © 
understand; the defining documentation [Vwij 69; VWij 73] 
presents an intimidating dorualias bo Cha unene ete: 
However, there are works (e.g. [Lind 71]) which are immense- 
ly helpful. 

Types in ALGOL 68 are called modes. Thé modes of rele- 
vance to us are the mode int (integer values) and the modes 
built from the mode-constructors struct and ref (structured 
and réference values, respectively). We G@escribe a corres- 


pondence which assigns ML-4 types to ALGOL 68 modes: 


ee ee aa 


= Tg ca ae oe eR peter ae 
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(1) To the ALGOL 68 mode int we assign the ML-4 
type int. 


(2) Tf Mi, cece are modes. and S rove By are tags... 
(the @quivalent of (selector)&) , the to the mode 
struct (M, s reece. Syd we assign the Mierd -type. - 
[Tv Syierert S.1, where the T, are the ML-4 types 
corresponding to the Mess. ae 


(3) If M is a mode then to the mode ref ae ae 
the type [T ptr], where T is the Mi type ‘corres~ 
ponding to M. 
Mode~declarations in ALGOL 68 are just Like type definitions 
in ML-4; for sr the idecdantaretion 
mode pair = struct(int a, int b) is equivalent eG the ML-4 
(defn) pair = [int a; int b]. ieee, 

A declaration in ALGOL 68, besides associating an iden- 
tifier with a mode and imposing type restrictions on the .. 
rest of the program, hae ce uosroia runtime: effect. con- 
sider a declaration of form M Xx = E, for instance ee = 3, 
where M is a mode, X = identifier, and E an expression © 
yielding a value of erred This declaration first binds X 
to a newly-allocated cell. Second, it places the mode M 
value yielded by E inte thie cell. What is° Meecuiiey about 
ALGOL 68 declarations is that this value can never be | 
changed. It ayy oeeves. be a reference Galie fi 22: the 
mode M is ref N for some other made wi, in the cane it 


refers to (points to) a cell holding values of mode N. This 
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latter cell (and not the former call) can be updated by the 
assignment operation in ‘ALGOL 68. ike ‘the meaning of 
assignment in ALGOL 88 aif ters from aaeignment an ene other 
degen we have Sisaiédea: Mote that “en daentitier whose 
declared. mode is not. a referanae made serves essentially as 
a constant. An identifier of mode ef N in ALGOL 68 plays 
| the ¢ game tole as a vatieple of type N in easter "Programming . 
language. | | = 

The specific definition of ALGOL 68 assignment is as 
follows: let E be an eS yielding a value of mode M 
(M can be arbitrary) and D an expression of sade. ‘ref M. 
The value of D is a reference to a cetl which ean n hold val- 
ues of mode M. Then D i= E isa valid aesignnent and 
specifies that the mode-M value of E is ‘to be ‘stored in the 


mode-M cell ‘referred to by (the value of) D. 


A particular kind of ALGOL 68 expression, Known as a 
iocal generator, specifies allocation ot * new coll when it 
is SYA IVEEOS: If M is a mode, then evalyation of the local 
generator loc M causes a new cell (which can only hold val- 
ues of mode X) to be allocated. The value yielded by joc M 
isa reference to this new cell and therefore belongs to the 


mode ref M. 
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To obtain a variable in ALGOL 68 which will take on 
values of a mode M, we must declare an identifier X of mode 
ref M so that assignment can change the mode-M vatues: 

This may be ‘accomplished ee means of an ALGOL 68 dep teracsen 
of form M X, which is | really an “abbreviation for the dec- 
laration oo M X = loc M. eonplder. for example, the | 
Aer. 68 jac acaries int x (equivalent. to ‘the desiacat ion 
ref int int x = loc int), whose: effect is “depicted in eegure: 
4.3~9. The identifier Xe :) which is coe here to be Of 


ude ref ‘int, is” 


pound to: the upper _ 


cell; the lower cell 


refint = fint ptr]; errs aliocated (by | 


| ‘efint Xe. 


X & refint [nil] evaluating “loc int 


‘Fig. 4.3-9.° Semantics of the 
ALGOL 68 declaration int x. a ALGOL 68, and by 
. . a . coaiuaeine he. 

(cell expr) nil = the cconstractilon): refint (nil) in 


ML-4); and the upper cell vaceiven. as (permanent) “alle a 


aM 


Berater to the jowas cell. ‘Subsequent erection. of the 
ALGOL 68 mmsicamenk X o:= 3. would place 1 the Galue: 3 in the 
lower cell; therefore its ML<4 equivalent Pe the (assignment) 


ptr of x €+ 3. aie seatles typechecking pokes: for ALGOL 68 


Ree ELS 
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insure that any assignment attempting to place a non-integer 
“yalue in the lower cell is detected ana’ indicated to be’ 
invalid. | 

| There is one aspect of the ; ALGOL 68 type system + which 
is more. lenient than the ML~4 system. unlike PL/L, m no > type 
errors can areas: from this loosening. consider ‘the assign 


ment y := X, where both identifiers x and y have been de- 


a 


ak 


clared to be of mode ref Ant. ‘This ‘assignment specifies | the 
updating of the mode int cell polihted to by y:. But the 
right-hand side, which must - then supply an integer walue, ie 
of mode ref int; according to ML-4° Rules, ‘the. asaighient is 
ae be rejecred se the translator as Anvalia. However, - 
ALGOL 68 recognizes that the ref int value of: = points to an 
int value, 80 all that needs to. be. done . te- tae ue re- 
quired integer value is follow the pointer ee this process 
is called dereferencing. In penerere the shila for ob 


taining | a value of a desired wed: ‘from a value of some other 


oe 


mode is. known as coercion or r gonversion. ‘thus, in the | 


ALGOL 68 type aysten, if the left~hand side of an assignnent 


BARAT ETT 


is of mode ref M, ‘then the assignment is valid provided the 


right-hand ide is of mode x or can ‘be ‘coerced to > yield : a 


‘at 


mode M value: In our case, ‘the Deccadice which Gianeieese 


tte ath AR ERE eS Sete tek ey 
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aon ALGOL 68 into acme must ea ahh that Here rerenciag i= 


Po ae 


éaliied for, mark the ee aia yo := X as legal, and ie 


re ges 


erate ML-4 code which takes the. coercion into sneouate of 


the three assignments in the example ahowh in. ples 4. 3- 10, 


coercion takes place only in the sécond oné (where y is = 


dereferenced). 


The y on the right=hand-side here is trans-— 


lated into the ML-4 (expression) ptr of y.. yielding a valid 


ML~4 (assignment), 


Note that the mode of 


x is int, and the mode 


of y and z is ref int. 


The concept of 
structured values in 
ALGOL 68 is essen- 
tially the same con- 
cept when taken by 
itself as in ML-1 and 
ML-2 (as well as PL/1 


and QUEST). Sharing 


refint =. Tank ptr]: 
| int x; : 
‘refint YrZ? 

x «+ a7 7 ie 
y ¢ refint [nil]: 
Zeg efi Ag (nil d+. 
ptr of y © x; 

ptr of z + ptr of y; 
ptr of y © «4 


eit sahara cassis Baath Ga ates dest Meer 


Fig<. 43-10. An example of 
coercion in ALGOL i 


"Arte tent nem pam mento emt 


arises only through the use of reference modes; assignment of 


structured values is done by componentwise copying. Figure 


4.3-11 gives an example. 


The mode of z is pair; the mode of 


-138~ 


x is ref pair. “The SRPEeneton (Ss. 6) in the declaration 
for z is called a structure displa y and simply gives values 


for the eee of Z. 


ALGOL 68 | 

mode pair = struct (int a,b); 
pair 2 = (5,6); 

Rair x; 


XK rs owe 


pair = [int a: int bl; 
refpair = [pair ptr}; 

pair z; xefpair xr 

z * pair[5;6é}; ee A 
x + refpair[paix([nil; ni]; 

a of ptr of x-+ a gf 2: Jf 
b of ptr of xe b of z 


Fig. 4.3-11. Structure ae aarti 
_ din ALGOL aoe 


The selection of components from a structure in ALGOL 68 
is syntactically identical to ML-4. In fig: 43-11, the sel- 
ection b of z, which refers to the b-comfponent cell of zy 
is of mode int. There is a major compiication concerning 
selection in ALGOL 68. we oan legally form the selection 
b of x, where x is of reference-to-structure mode. The mode 
of the selection bof x is ref int. not int ‘even though 
the b-component cell for the structure pointed to by x in 


figure 4,3-E1 is of mode int. We say in this case that the 


Bethe eye oh 


acs PRES. Hae Pees ae ea IPE 
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iglaes is distributed over: fhe. omponen’s (An BUGOE 68 

terminology, x in “endowed with Subnames") . _mbus. for ax 
ample, the assignnent b of x := a of 3 z Feo) egal; : in the 
ALGOL 68 program of fig. 4. 3~11 at Mould | place the value uD 


into the b-component cell of the structure pointed to by x. 


Unfortunately, the "obvious" translation into ML-4 - 


fails. The ML=4 type refint, defined as [int ptr], corres- 


ponds to the mode xef int, but in/fig. 4,3-11 there is. no. 
cell of this type to associate, to..the (deatination) that. . 
corresponds to the ALGOL 68 selection bef... Thus, in 
translating from ALGOL 68. into. ML-~4, - such, cella. must. be 
added to the picture (these cells — eos Pointers to the 


individual components of the structure referred to by se 


The corrected translation mechanism ae shown in fig. 4. 3-12; 


7 paix = [int a; b]; | 
fpair =* see 7 

int = [int boa 

gbpaizet: eri f’srrestay b]; 


x + refphir{ pal neha 
‘x$sub © subpats [zee 


| ptr of a of x$eub- - 3; 
, {| ptr. Seb: Sf xGsth @°ptr’ — a ot ata 


Are a ot ptr es x: 


ee 
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for each reference-to-structure identifier ¢ we add tothe 
local structure a reserved identifier x$aub to hold the © 
subnames (distributed ‘component pointers) hs By iBoKing ~ 
the local structure pictured in fig. 4.3-12, we see that 
there are two ways to access component célis of the struc- 
ture pointed to by x: through x (with ({aestination) 

b of ptr of x) as when updating the structure itself by ‘com- 
ponentwise copying; or cawooe: x$sub ‘(with (destination) 

ptr of b of x$sub) as when explicitly selecting from x using 
subnames. Note that our translation cdri¥orms to the stip- 


iy system. 


ulations set by the ML-4 ‘static 


We give a final ALGOL 68 example, illustrating a re- 
cursive structured mode. The example is shown: in ‘figure 
4.3-13. box is a structured mode, recursively defined, and 
a and b are of mode ref box. Note that the mode-of the. sel- 
ection nofa is. ref ref box. The éeily SSercion1a/the 
program. occurs in the last assignment, where a is deref- 
erenced. A recursive mode “definition auch. ae _ 
mode badbox = struct {int v». ‘padbox ‘ny would be titegal; the 
"ref" inside the definition of the mode: bax, is necessary 


since there is no implicit - nil in ‘ALéot, 68's rioden as there 


is with ML-4. 
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Thus we see that even with a language as complex as 
ALGOL 68, we can use ML-4 to make clear its approaches to 


the semantics of data structures. 


ALGOL 68 | 


mode box = struct(int v, 


box = [int v; refbox n]; refbox = [box ptr]; 
subbox = [refint v; refrefbox n]; 
refint = [int ptr]; refrefbox = [refbox ptr]; 


refbox a,b; subbox aSsub,bSsub; 


, a ¢ refbox[box[nil;nil]]; b + refbox[box[nil;nil]]; 

a$Ssub ¢ subbox[refint[share v of ptr of a]; 
refrefbox[share n of ptr of a]]; 

_, b$sub «+ subbox[refint[share v of ptr of b]; 

refrefbox[share n of ptr of bj]; 


| ptr of v of a$sub + 8; e 
ptr of n of aSsub ¢ b; Fig. 4.3-13. Final 
|v of ptr of be v of ptr of a; ALGOL 68 example. 

n of ptr of 


benof ptr of a 


Completeness 


In this chapter, we defined the mini-language ML-4 and 
used it to model data structuring facilities of the lan- 


guages ALGOL W, PL/1, and ALGOL 68. As in the last chapter, 
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we close with a few Senazins on “the completeness: of our cov= 


erage Be the approaches to data structures found in these — 


three languages. 


With ALGOL W, as with SNOBOL4 in the previous chapter, 


wee covered nearly all the data structuring facilities thor- 
‘oughly, With the exceptien. of arrays. We comment on arrays 


and some wf their. special issues in Chapter 5. 


For PL/1. and ALGOL 68, our treatment is far from com= 
plete. This is to be expected because. of the sheer’ ‘bulk and 


Pare 


complexity of these bee tanguaged. 


“mere ice numerous _ 
features dealing with data: structutes Mate we have not de- 
scribed.’ Yet we claim that those ‘features “witen we did de- 
scribe in PL/1 and ALGOL 68 constitute the “heart” of their 
data Scaccieiag facilities; thus our description of, thee? 
features should make Clear the underlying: semantic approaches 


to data structures in these Languages: as: well. 
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Chapter 5 


CONCLUSIONS AND EXTENSIONS 


“5.1. What We Have Done 


There are a large number of Pprogranming languages. which 


Sul hi 


work with data structures. Because of the variety of ap- 


_ proaches found in these languages, many subtle but important 


semantic distinctions crop up. With most languages, the — 
semantics (including in particular the semantics for the | 

data structuring facilities) are described informally in_ 
English. We consider such descriptive methods inadequate 

for our goals, since in wany..cases they fait.to make clear 
some of the. wPOE Ean’ semantic principles such. as sharing. 
As we have seen, a nisunderetanding of the interaction > pax 


eyeen” notions such as _assignnent and sharing can lead the” 


programmer into erroneous "conclusions about the effects of 


programs. 


We have therefore developed in this thesis a method- 
ology for describing the semantics of data structures in 
programming languages. In order to precisely describe mech- 


anisms found in programming pana: wate handte data 


structures, we made. use of the base ) language model, which is 


ate 
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an interpretive model for ‘formal semantics. The base lan- 
guage model is essentially a mathematical formalism for 
modeling the changing states of a hare cabs system on Which 
various computations are performed. A mathematical fraxtce 
ment of the ‘base Language model is fourd in the Appendix; 
ovr approach onghasined ‘the use of thé base language as a 
Grodeamaing Woot similar to many conventional assembler lan- 
guages. A major advantage of the base Language model over 
other formal semantic models is ‘that it maridipulates data 
objects of a sufficiently general nature that we can make 
direct use of ite data representations in our work without 
need fox ‘apactal encoding nectasi tins. : 

The main portion of this thesis was en ed with the 
presentation and use of a series of wini~Languages. with 
these mini-Languages, we isolated ‘ha relevant conceptual nx 
abstractions such as aceliaent: vitee., construction, geiecs 
tion, enariag and typechecking. The mini-languages ab aded 
a "high-level" ‘aeseriptive vehicle whieh made it simpler and 
mote coAvenient to talk about semantic i#sues relating to 
data atructures : | 

The basic structure of our ue methodology was to first — 


axe Clear the semantics of our mind ~languages by specifying 


BeBe Pei Ginter ge ee ee hed SS A Pea ee + 


-145- 


their translation into the base language. Once this was 
done, we no longer needed to think in terms of the primi- 
tive operations of the base language. We were then able to 
describe the semantics of data structuring features in some 
programming language by simply using the appropriate mini- 


language to describe how the relevant mechanisms worked. 


In treating the data structuring semantics of several 
programming languages, we gave mini-language code into which 
constructs of these languages are translated. Determination 
of this mini-language code presents difficulties when the 
semantics of the source language is incompletely or ambigu- 
ously specified, reflecting the inadequacy of the descrip- 
tive methods in use. Of course, once we have obtained a 
consistent translation into the right mini-language, we have 
an unambiguous semantic specification of the relevant con- 


structs, 


Using the techniques we developed, we described the 
data structuring semantics of a number of representative 
programming languages. With the simpler languages, we were 
able to give a nearly complete treatment of the data struc- 
turing facilities. As to the more complex languages, we 


were able to cover most of the fundamental approaches to 
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data structures without getting caught up in the intricacies 
of features of relatively little semantic relevance to the 
issues we are concerned with. In the next section, we talk 


about some of the areas that were left uncovered. 
322. Furt Wor 


There are a number of semantic area that we have not 
treated. In order to cover these ateas, we would need to | 
_ develop new mini-langquages with ad@itienal mechanisms. In’ 
this section, we give brief mention to two. such areas and 


what kinds of new mechanisms are required to treat them. 


The first uncovered area is unions. With the type sys- 
tem of ML~-4, every cell is constrained to hold values of 
only one type. In many programming languages, this restric- 
tion is weakened somewhat by defining union types. If type 
t is the union of types tl and t2, then a cell of type t can 
hold values of type ti as well as values of type t2. For 
example, suppose we declare z to be of type t in some wae 
guage that admits union types, and suppose tHat the express-~ 
ions el and e2 yield values of types. tl shet2, -respective- 
ly. Then both the assignments z := el amd z:= e2 would 


be legal. This capability is not within the reach of the 


HERI MET Be ae ME PAR ORR SAE PAE ORES ORE “aE ea eA 
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type pechensems we Sais a sox iaiaehe Suppose we declare x 


. to be of type tl. Then the adaicanent wre oe pie be aces 
cuted without type error precidety ‘When’ the vdlud of z is of 
type tl rather than of type t2. “8d°-ii’ ‘oer té aad ‘to our 
mini-languages a capability to handte’ ‘in Sti ‘gome ‘kind’ of © 


additional runtime’ type testing methanishfimet' Be intro~ °' 


duced into the design of the langtiage." 
The second uncovered area is arrays. “me type system 


of Mr—4 is simply | not ‘equipped ‘to. deal with | arrays whose 


ety! Sag 


subscript bounds are -Hlexibie: “dhe eps ‘on such an array 
would oneal. | structures having differing numbers of com— 
ghey 


ponents. A structured type an ML~4 requires a set of selec- 


tors which is ee to the translator ana caanos change. 
Even with unions, we are no ‘better oe. “For: instance, the 


onal 1 


type consisting of all PAL tuples could’ not. even be expressed 


aS a finite union of ML-4 ey oe eee a ‘tuple « can ‘have any 
one of. an “infinite number of ree oe sets a, oh 2), 
PTe273 4. wok fly eeesem a Gta 

There are many other complicated issues concerning 
arrays, such as different array type concepts, - change- 


ability of bounds, and assignments between fixed and flex- 


ible arrays. All of these issues introduce new complexity 
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into the language, requiring the development of more techniques. 


To sum up. our methodology for describing data struc- 
tures has special advantages from each of its two portions. 
The use of the hase language model provides for a precise, 
formal characterization of the semantic rules of the lan- 
guages under prey a while our mini-languages provide the 
convenience of high-level descriptions of the actions being 
modeled. In order to describe — programming language 
feature, all that needs te be done is construct an appro- 
priate mind=language which handles aay the gancepts direct- 
ly relating to that feature. The syntax and semantics of 
such a mind-Language are Aatueadiy rere eek Wick a 
understand. By anacu mite translations from source lan- 
guages into the mini-language and from the mini-language 
into the base language, we gain a precise but scnceptualiy 
Sewc chavedtextention of the Samahtiea of the features 


we wish to study. 
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Appendix 
A MORE FORMAL TREATMENT OF BL 


An interpreter atate enbodies the information present 
ata given time ain. the computer syaten we 228 ‘modeling. In 
this Beckson we describe in Serer a structure of BL- 
graphs representing dntarasehas auites: in--the pase jangiace 
model. ‘The -krestnent here differs somewhat fron ‘[Penn: 71) 
and {Amer 221, but is eaneatisily eeeivalant:, In the next 
section we ‘formalize BL~graphs and the BL anatructions. 

We assume that the reader is familiar with the concept 
of process as a locus of control. A process is represented 


in an interpreter state by a BL-object which we call a site 


of activity, or SOA. The BL-graph for an interpreter state 
is essentially a collection of SOA's. The root nodes of 
such a BL~-graph are the root andes of its SOA's. Thus an 
interpreter state is represented — | 


by a BL-graph whose skeletal 


form is shown in fig. A.1l-1. 


WPig. A.l-l. Skeletal 
structure of BL-graph 
for interpreter state 


We now describe the struc- 


ture of the individual SOA's of 
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an interpreter state. A SOA is a BL-object with four com- 


ponents: 


(1) The ep-component is a local structure, a BL-object 
representing the environment in which the SOA's computation 
takes place. (The name "ep" is an abbreviation for environ- 
ment pointer.) Components of a local structure represent 
variables and temporaries used by the computation. Nearly 
all the BL instructions executed as part of the computation 
affect its local structure. We allow for the possibility of 
different SOA's sharing the same local structure, but usu- 
ally the local structures of the different SOA's are dis- 


tinct. 


One distinguished SOA has as its ep-component a BL-~ 
object known as the universe. The universe represents the 
system-resident information present in the computer when no 
computations are in progress. Generally speaking, this in- 
formation is independent of which computations are currently 
active or how far individual computations have progressed. 
This special SOA stands, so to speak, at the head of the 
system call chain, so that every process can trace its an- 
cestry back to it. Access to the data in the universe is 


passed from caller to callee, so whatever access a partic— 


abet a cepa sdanin epee 
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ular SOA has to the universe is determined by the call chain 


leading back to the one sa a SOA. 


Two kinds of objects are anions as "components in the 
universe: data Structures and procedure structures. Each 
kind of CRIeet ean have objects oe either kind as compo- 
nents. A data structure in the model can be! any arbitrary 
BL-object; a procedure structure is. a special kind of BL~ 
“object representing a procedure expressed in the base lan- 
guage. A BL instruction is” easily represented as a BL~ 
Sbject; for matte: the instruction “sonst 3, x is depict- 
ed in figure A.1~-2. The eemesonen te | 
with selectors i eee of a procedure 
structure are: simply representations of 


its instructions in order. A procedure 


‘Pig. Ac.l#2, A 

| Sample BL in- 

- | struction as 
| a BL~object. 


structure may also have components 


which are procedure structures for nest- 


ed procedures. Figure A.1-3 illus- 
trates a skeleton procedure structure for a procedure p 
with one procedure f nested inside. 

(2) The ip-component of a SOA gives the instruction 
currently being executed by the SOA's computation, as well 


as the procedure containing this inetruction ("ip" atands 


yn, Pha SE Se 2 AA 
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for instruction pointer). The ip-component is a two- 
component structure, whose proc-component gives the current 


procedure structure from which 


instructions are being executed, ete Sota 


. arr n 5 
and whose instr-component gives ted 
component g tn af ri cdune 
nste 
ot fF 


nth Bu Str octure 
: : Lye far L 
the number of the instruction ae 
Be cela t 2A 
currently being executed in tt 
K+ Be mt 6u 
1NSty. Wr, 
this procedure (fig. A.1-4). ee Uw ES 


noon sere te aimee 


Fig. A.1l- 32 of sample 


Thus the instruction currently | procedure structure 


being executed within a. SOA s 
is given by the dotted pathname ip.proc.*(ip.inst), taken 


relative to the root node of s. 


(3) The stat-component of a 


SOA, which gives its status, is an inc 


. Fig. A.1-4. ip- 


1£ the SOA is dormant. component of a SOA! 


elementary object with the value l e vas 

when the SOA is active (i.e. curr- So QL etn 
| 

ently processing instructions), 0 
| eos 
i 


+( 
eet | 
| 


(4) The ret-component of a 
SOA s shares with the SOA that invoked (created) s. When 
S executes a return instruction, the SOA given by the ret- 


component of s is activated; the current SOA is put to sleep. 


CIE STD Str ORRg, Seete PES ae SAPS eee, 
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with the structure of an interpreter state given atere: 
we can procesd ‘tothe next section, which | ‘manceibes ‘how the | 


BL instruetions: transform interpreter states. 


We give a formal mathematical definition of BL~graphs. 


Suppose the sets ELEM (elementary objects), SEL (selectors) 


and NODES” (nades) are ass Yor our Purposes, ‘ELEM shall 


Be: 


consist. of integers 


hi shall, consist ed integers and strings: and | MODES. hal. 


be an arbitrary countably infinite eat. | strings are | taken 


over Bone suitable alphabet — which, includes the siphanuneric 


See he Fg 


characters together with some epecia” “e sters. A 


| Bucarabh PRR these three sets isa stele “g = (U;R-A,V) 
“in whieh: SB AENS SNP MRS oe GEA es ee 


U- s(nodes, in use) “is a finite ‘atieat | of" add 
¢ tr: whee Fete : ae ee 
: c wu x SEL x VE Seen 
: . es eae 


We interpret fave, B)’ € A to ‘neat { oe ae’ “ibiveivea arc. 


with selector o leading ‘ted ni @ 0 Hoda * ‘Bs 


(sy eve “to mean “a ts a eat nadé with siémentary value 


say 


é. A Bi@grapn 9 man ‘tattngy ‘the ‘Seite ding four sowditions: 
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(1) If a € U, o € SEL, then there is at most one fB € U 
for which (a,0,B8) € A. 


_(2) Ifa EU, then there is at most one 6 € ELEM for 
which (a,6) € V. 


(3) pr, (A) al pr, (V) = ¢, where Pry is the first-— 


component projection mapping. Equivalently, 
Yae€U: w[#6 € ELEM: ((a,6) € V) 
& g(o,6B) € SEL x U: (a,o,8) € A]. 


* * 
(4) D (R) = U, where D is the reflexive transitive 


closure of the immediate-descendant mapping 


De rh + rial defined by 


D(S) = [8B € U: gaé€ES, o € SEL s.t. (a,¢,8) € A}. 
Property (1) insures unique selection, i.e. that the selec- 
tors on the arcs emerging from a node are distinct. Prop- 
erty (2) asserts that no node may have more than one elem- 
entary value. Property (3) says that no node may have both 
components and an elementary value, i.e. that elementary 
values can be attached only to leaf nodes. Property (4) 
states that every node of a BL-graph is accessible along 


some directed path of arcs starting with a root node. 


We now give a formalism for defining transformations on 
BL-graphs. The formalism is based on [Denn 74]; it makes 
use of a set ID of identifiers and a mapping 


v: ID UY ELEM YU NODES ~ ELEM NODES which assigns values 
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to identifiers and acts as the identity function.on elem- 


entary values and nodes. A basic transformatian maps a 


BL~-graph g = (U,R,A,V) into a new graph g* = “fU';R',A',V') 
and updates the valuation mapping y imto a new trapping v'. 


The notation y[a/x] means iy. (y=x 4 a, true + v(y)), i.e. a 
mapping equivalent to y.except: that it maps x into a. 


Pipe: eee ‘basic transformations and: muri Liary 


functions are defined for arbitrary BL~grapha: a 
AddElem(a.d): [defined provided u €'b, 6 € ELEM, 
_ Where a = y(a), & = v(d)] 

vee v uUf(ta,é)}, Wo= OU, R eR, OAD eA, yt = y. | 
‘DeletePlem(a ad): (defined provided @ €U,°s € 2LEM and — 
| (a,6) €V, sihene a= v(a), 6 = v(d))_ 

v' =v - {(a,8)}, Uli =U, R'=R, A' =A, vis 
nadare(a/8,b) : [defined provided a,8 € U, o € SEL, 

where a =.y(a), 0,%.(8), B= ub) ] 

A' =A : {(a,0.B)}, u' = U, R* = R, ¥". = ee, ne = ve 

pelekeatata;ash) 3 [defined provided “Be €. U, o € SEL and 


(a,07By € 4K, Whete o = eutay oO = vfs), 
B = v(b)] 


A'=A = f (aso +B) }> U' = U, Rt s R, v! ae wo. v' le Ve 

| ‘Déletecomps't#) : [defined providedo€ U, ‘Where'd = \ (a) ] 
OAT = AN EU @ fe)).-~ SEL. x UU), B= Uy Rive R, .. 
VieV, y' = yy. 


a ce ea 
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Prune: 
Un D (R), R' =RNQU', A' =AN (U' x SEL x U"), 
Vi=VA (U! x ELEM), vi =v. ae 
HasComp(a,8): [defined provided a € U, co € SEL, 
where a = v(a), o = v(8s)] a 
if mw € U: (a,9,B) € A. then true elge. false. _ 
Comp (a.8) +. bh: [defined provided & € ay @€ SEL.and 


: HasComp(a,s s) = true i.e, 28.€ U: (a,0,8) € A, 
where a = via), ¢ = v(s)] 


det BeéeU such that (a,0,B) € A; : 
v' = y[B/b], U' =U, R' = R, A' =A, Vim Ve 


. HasElem(a) =. [defined provided a€éu, where. oe cuptahy 


if 4 €: -ELEM: (a,8) € V then true -eise false. 
Elem(a) ~ d: [defined provided a € U and ‘HasEtem (a) = true. 
i.e. G§ € ELEM? {a,'6) °€ V, where a = y(a)] 
let § € ELEM such that (a,8) € Vros' & 
v' = y[6/a], U' =U, R' = B.A! eA, WN BVY 


NewNode ~ a: 


let a € NODES ~- U; 
vi = yv(a/a], U' = UU fa}, RI = Ry ALLS A, V! =v. 


/ MakeRogt (a) : | [defined provided o €.U - R, where a. = v(a)) 


Re = RU (al, u' =e A' mass vi=v, em 


senavatant (al [detinea provided d F R c U, where a = y(a)] 
=U- fa}, R'=R™= fa}, ae Re GaN VOCs ye ee 


The following transformations are composites of basic 


transformations: 


Sea BeBe ERS EE BORE es ey, 
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NewComp (a, 8) + b: 
NewNode + b; [n. b. the semicolon indicates cqm- 


position 6f ‘tran@formations, with 
AddArc(a,s8,b) application in the, ,order shown] 


DeleteComp (a,8): boa a el 


if HasComp(a,s) 6 [thé composite trans forma- 
. tion in. the set hraces is 
one ae he - epgined ff ‘the node de- 
Deletesre(a,s bd; yy a has a component 
veh Hie ector denoted by s]} 
Prune}. ae aah 
‘MakeEmpty(a,8). + b: ee 7 friakes b abes an empty 


: node which is the 
ent of the node 
then {Comp(aseyoobro denoted “By ‘a} 


af HasElem(b) 
then {Elem (h). * “aye 
ERS ae eS ee 
“gle [Deletecompa tb); | 
Prune} } | 
else NewComp(a,s) + b. 


if HasComp(a,s) - 


We now have the machinery ‘to deseribe the action of the BL 
interpreter. “the basic action is to pick root node, which 
will be some SOK, then to mass the mere instruction . 
(given. by the ip-component of the SOA) with reapect. t to the 
current local structure (given by the ep-component of this 
SOA). Figure A.2-1 illustrates the skeletal stiicture of a 
sample SOA, In the procedure we will give to définé the . 


action of the interpreter, special names are us@& to des- 
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ignate nodes in the current SOA. These names appear as 


labels for the nodes in fig. A.2-1. 


Toot nodi of 
eat poet 


ram sae ee 


eh odes 


Fig. A.2-1. Structure of a SOA — 
during dnterpretatien: Cae aati es 


Before giving a procedure which specifies. the action of 
the BL interpreter, we define several hapainttes? A PPARs forma: 


tions. Thege yse..the .special.names shown,in fig. ‘A, ade ae 


1 eed 4 
en i 


Pi ckactiveRoot + Root: 


let a €R such “that a8 €U: (a, ‘etat'.B) é A ‘& (B.1) € Vv; 
yl yIe/root], U' =U, R' =R, A' =A, ve = ve 


Sige Senex tie eee ee ee 
v' = vintl/next], U' =U, R' = R, A' =A, V' =V, 
where KR = Vy (k) a! aa : % fe : hay a Mr kA Se 
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GetNextInstr: 
DeleteElem(inum,k) ; 
Ad@Elem(inum,next) . 


Jum i 41 ext: [defined for t € {O, 1,2 p00<} S ELEM, 
where « = y(i)] 


y' = viv/next], U' = U, R' <=R, A’ = A. V'=V. 


Empty(a): [defined for a € U, where a = y(a)] 
if HasElem(a) . 


then false 
else if Io € SEL, B € U: (a,0,B) EA 
then false 


else true. 


The action of the BL interpreter is specified by the repe- 
titive application of the traneformation given by the follow- 


ing procedure: 


PickActiveRoot + root; /* pick an active root node */ 
Comp(root, "ep') + cls; f* access the ¢.1.s8. via ep */ 
Comp(root,'ip') + ip; 

Comp(ip,'proc') + proced; /* access procedure structure */ 
comp (ip, 'inst') + inum; /* number of current instr. */ 


Elem(inum) + kK; 


Comp(proced,k) + inst; /* fetch current instruction */ 
Succ + next; /* set for next’ instruction */ 
ExecuteBLinstruction(inst); /* execute the instruction */ 


GetNextiInstr. _ /* veset ip for new instr. * / 


PEGE ee 2 TURING ee ce RE ote pte eat 
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Finally, we define the operation of all the BL instruc- 
tions by giving the transformation ExecuteBLInstruction. 


ExecuteBLinstruction (inst) : 


Comp(inst,0) + operation; 


case operation of /* choose the action that matches the 
operation code of the instruction */ 
‘create’: 


Comp(inst,1) + x; - /* create x */ 

DeleteComp(cls,x) ; 

NewComp(cls,x) + a. 
‘clear': Siig ies ite Ue, 
Comp(inst,1) + x; _ #* clear x */ 
MakeEmpty(cls,x) 7 a. aoe 
‘delete’: 

Comp(inst,1) + x? 

if —Hascomp (inst, 2) = ae 

then DeleteComp(cls,x) /*. delete x */ 


else {Comp(inst,2) + m; /* delete x,m */ 


if HasComp(cls,x) 
then {Comp(cls,x) + a; 
DeleteComp(a,m) }. }. 

‘const': 

Comp (inst, 1) + Ve 

Comp(inst,2) ~ x; : _. /* sonst v,x */ 

MakeEmpty(cls,x) ~ a; 

AddElem(a,v). 
‘add': 

Comp(inst,1) 7 x; 


Comp(inst,2) 7% y; 
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Comp(inst,3) # z; /* add x,y,z 
Comp(cls,x) + a; Comp(cls,y).+ bi "Se 
Elem(a).+'d; Elem(b)-+ e7 

MakeEmpty(cis,z) + c; 

AddBlem(c, 4 (4)-+y(e)) - 


/* other arithmetic instructions are similar _ 


‘link’: 
Comp(inst,1) + x; 
Comp(inst,2) ~ nm; : 
Complinat,3) + y: /* Yink Xn vy 
Comp(cle,x) + a; Comp(cls,y) + ‘b; Rg he 
if HasElem(a) 
then {Elem(a) + d; barecestan(ti)F 
else DeleteComp(a,n); z 
Aa@Are(a,n;b) . 
‘select’: 
Comp(inst,1) 7 x; 
' Comp(inst,2) 7 n; 


te hig etter amg ne ahs pe TT te ERS Qe ey 


‘/ 


ad 


*/ ) 


Comp(inst,3) + y; /* select x,n,y */ 


Comp(cls,x) + a; 
if —Hascomp(a,n) 

- then fif HasElem(a) 

then fElem(a) ~ d; 
_ DeleteElem(a,d) }; 
NewComp(a,n) + b} 
elise Comp(a,n) + b. 
‘apply’: | 

Comp(inet, 1) + p; 
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Comp(inst,2) + x; /* apply p,x */ 
Comp(cls,p) + proc; Comp(cls,x) 7+ arg; 
Comp(proc, '$text') + t; : 
NewNode ~. newsoa; 
NewComp(newsoa,'ep') ~ newcls; 
AddArc(newcls, 'S$par',arg); 
NewComp (newsoa, 'ip') + newip; 
AddArc(newip, 'proc',t); 
NewComp(newip, 'inst') ~ newinum;- 
AddElem(newinum,1); 
NewComp (newsoa, 'stat') + newstat; 
AddElem(newstat, 1); 
AddArc (newsoa, 'ret', root) ; 
MakeRoot (newsoa) ; 
Comp(root,'stat') + stat; 
DeleteElem(stat,1); AddElem(stat,0). . 
‘return’: 
Comp(root,'ret') + oldsoa; 
Comp(oldsoa, 'stat') ~ oldstat; 
DeleteElem(oldstat,0); AddRlem(oldstat,1); 
RemoveRoot (root); Prune. 
‘move’; 
Comp(inst,1) 7» £7 
Comp(inst,2) + x; : - fe move £,x * / 
Comp(proced, f) 7 a; re as 
DeleteComp(cls,x); AddArc(cls,x,a).— 
‘goto': 
Comp(inst,1) 7 4; /* goto £ */ 


Jump(g) 7 next. 
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‘elem?'; 
Comp(inst,1) +.x; 
Comp(inst,;2) 9% £7 — | 
Comp(cls,x) ~ a; 
if _HasElem(a) | 
then Jump(4) + next. 
‘empty? ': 
Comp(inst,1) + x; . 
Comp (inst, 2) + A? 
Comp({¢cls,x) + a; 
af ~Empty (a) 
then Jump(2z) + next. 
Comp(inst,1) + x; 
Comp(inst,2) +4. 
Comp(cls,x) + a; 
L£ Empty (a) 
then Jump(4) + next. 
‘eq?': rai he 
Comp(inst,1) 7+ x; 
Comp (inst,2) + y: 
Comp(inst,3) + 4; 
Elem({x) + d; Elem(y) 7 e; 
Af v(d) # vile). 
then Jump(s) + next. . 
"has?': 
Comp (imet,1) - x; 
Comp (inst,2) + m; 


jE Ste Aer A ia TE Reet Rte ee Wt saat ey So att Ce See: = 


sn 
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Comp(inst,3) 7 4; /* has? x,m,2 


rp 


*/, 


Af -HasComp(x,m) 22-0 0 ReS ene sode aaa! 


then Jump(s) + next. 
"same?': 
Comp(inst,1) + x; - ie A Ghee 
Comp(inst,2) + y7 | . 


comp(inat.3) +45... ‘Bane? cys 


if v(x) # v(y) 
then Jump(4) 9 next. 
/* other  empartson gator charac dp eee uate 


‘getc': 


Comp(inst,1) + x; 


F 7 


Comp(inat,2) 9.45 coe crise) ln) pie. teed 


Comp(inst,3) 7+ 4; /*, Gate Kikyt 
 Comp(cls,x) + a; ere eee ad br, 

if HasUnmarkedComps (a) 

then -fGetunnarkedcomp (a) ey Aho 

_Mark(a,8); 

AddElem(b, 8) } . 
f{UrimarkCompsOf(a) ji 5 ee 
Sump(t) * next}. 2 0 ey ts, 


tg 
ae 
mer 


@. 
® 


endcase 


This completes the definition of the transformation 


ExecuteBLIinstruction. The get¢c instruction, however, 


requires some special additional mechanisms, which we now 


show. 


7 
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Hasv: rkedcomps (a): [defined provided a €.U, where.a = y(a)] 
if Go € SEL: (a,c,8) € A for some 8.€.U 
- and o € MARKSET (a) 


then true else false. 


GetUnmarkedComp(a) + s: [defined provided a € U and 


aoa amma te ie ‘= true, where 
= y(a)] . 

let oa ¢ SEL be as in the HasUnmarkedComps, predicate; . 

v' = vic/s). 


Mark(a,8): [defined provided a € U and go € SEL, where 
a= y(a), o = v(s)] 
MARKSET (a) © MARKSET(a) U {co}. 


Unmark sOf(a): [defined provided a € 'U, where a = y(a)] 
MARKSET(a} ¢ 9. gs 
We observe that each node a ¢€ U has | a set MAES (a) asso- 


ciated with it. All such marksets - are initiahly empty. 


There is one final remark to be made. Although our 
definitions of the BL instructions cantain many composite 
transformations, the interpreter is to regard the effect of 


a BL instruction as an indivisible unit. 


